Melkij

primary key нужен всегда.
Если по логике вашего приложения одному user_id может соответствовать только один пользователь в каждом service_id - то PK на первые два поля.
Если несколько - то pk на 3 поля.

Порядок полей при указании PK таблицы связей важен. Для mysql/innodb очень важен, т.к. таблица кластеризована по PK и любое обращение по вторичному ключу влечёт поиск по PK (кроме покрывающих индексов). Порядок выбирайте исходя из наиболее частых запросов к таблице, чтобы максимум запросов могло идти по первичному ключу.

Есть ли в распараллеливании запросов рациональное зерно?

Есть, если треды не дерутся за одно и те же ресурсы. Например, ходят в физически разные кластеры БД.

Получается, что один последовательный запрос, что несколько параллельных, имеют сопоставимую продолжительность.

Или вы неверно описали наблюдаемый результат или же параллельное выполнение медленнее в 2 раза и дальше ухудшается при конкурентной нагрузке.

На каком-то этапе параллельные запросы также выстраиваются в очередь.

Запросто. Но на вашу наблюдаемую картину не похоже, у вас время выполнения работы выросло в несколько раз.
Значит процессы дрались за ресурсы и очень сильно мешали друг другу.

Если в то же время подать аналогичные запросы с другого клиента, то время ожидания ещё больше растягивается.

Что подтверждает диагноз. Ресурсов для параллельного выполнения нет.

Поскольку вопрос затрагивает субд и вы не называете, что там происходит - самое очевидно - вы упёрлись в диски. Возможно даже в механические диски. Добавление новых io задач на диски ожидаемо и очень сильно замедляет весь остальной io.

PHP не делает различий между списком и нумерованным списком. Массив json же ключи иметь не может. Поэтому в попытке сохранить ключи массива json_encode делает объект с числовыми ключами. Для получения json array необходимо сбросить ключи массива, например:

$myArr["features"] = array_values($myArr["features"]);

перед вызовом json_encode

Проблема - условие WHERE работает только для первой таблицы, а из второй выбираются все элементы.

Вывод неверен. Выполняются оба условия, гарантированным seqscan'ом по events, если повезёт то index scan'ом по weekday. А в результате, как в запросе и написано - выборки перемножаются между собой в cross join.

Если таблицы не связаны и нужен плоский список - то здесь нужен именно union all. Глупая доктрина его не умеет. Возможные методы извращения без union глупая доктрина не умеет тем более.
Значит или обучать доктрину делать union all (вероятно, нетривиально)
или делать два запроса (всё равно у вас сейчас seqscan, значит производительность вам не нужна и explain никто не смотрел)
или делать вьюшку в базе с union all и ходить к ней вместо таблиц (и проверить, умеет ли планировщик каждой из поддерживаемых баз вообще прокидывать условия внешнего запроса во вьюшки с union all)
или использовать native query с нормальным SQL

PS: да, я с доктриной работал и именно поэтому её сильно не люблю за ограниченность синтаксиса, при том всё равно с нещадно текущими абстракциями и необходимостью знать и учитывать чем именно каждая поддерживаемая база отличается от других. И нафига эта доктрина тогда вообще жрёт столько cpu и памяти?

Обновляйтесь на актуальный релиз дебиана. Открытый radeon драйвер 2012 года и 2017 - две очень огромных разницы.

Или ставьте проприетарный. Не уверен только, который. В описании fglrx в пакетах дебиана уже не говорится про 4ххх серию, но вроде бы поддержка 4ххх была до 13.1 драйвера. Если не запустится, то пробовать ставить fglrx-legacy-driver из бекпортов)

Детали неудачного создания FK надо смотреть в innodb status, вы всё верно прикрепили в вопросу.
Встречный вопрос вам: что именно в объяснении английским по цвету вашего терминала непонятно написано:

Cannot find an index in the referenced table where the
referenced columns appear as the first columns, or column types
in the table and the referenced table do not match for constraint.

? На target таблице нет подходящего индекса для работы FK.
Судя по названиям - где вы продолбали primary key?

Ну и, конечно, нафига вам 4 одинаковых FK? На всякий случай?

payed_until timestamp default null
Если null либо в прошлом - значит срок оплаты прошёл. Если в будущем - значит оплата была.

Вы, видимо, будете крайне удивлены, но - с чего вы решили, что у хоста вообще может быть только один IP?
Хоть несколько сотен адресов на каждом сетевом интерфейсе.

И чем вам не нравится 127.0.0.1? 127.0.0.1 - отличный адрес. Он есть чуть менее чем у каждого хоста. Помимо него у каждого же хоста может быть любое число других сетевых адресов. В том числе из более чем обширной сети 127.0.0.0/8 - вся эта орава является локальными адресами.

И это только для ipv4, и даже без учёта трансляции адресов. Для ipv6 by design существует множество адресов на всех интерфейсах.

Начните изучать булеву логику.
(a and x) or (b and x) or (c and x) === x and (a or b or c)

Вот так вкратце исполняется запрос в mysql.
Циклов внутри много.

Как выгрузить из бэкапа нескольких БД одну необходимую?

бэкап всех БД - all_databases.sql

Никак.
Либо идти руками и текстовым редактором доставать именно нужное.

-U - существующий в postgresql пользователь, от имени которого можно зайти сейчас. А не после разворачивания бекапа. Для бекапа всего кластера очевидно понадобится суперпользователь, postgres или pgsql обычно.
-d имя базы данных, а не таблицы. База так же должна уже существовать, чтобы можно было подключиться к pg.