Melkij

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

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

И пусть. Нормально сделанной базе плюс-минус лям пользователей - не вопрос.

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

С этим сложнее. Если есть пользовательский контент - то сначала необходимы люди, которые будут его модерировать (не забудьте сделать внятный инструмент модератора для поиска и удаления пачкой комментариев по шаблону). Антиспам автоматика не исключает необходимости в людях, которые будут проверять вручную. Вы видели спам на stackoverflow? А попадается и там.
И капча, разумеется, не панацея тоже.

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? На всякий случай?