Алексей Сундуков

Попробуйте через with как это описано в Eager Loading: Eager Loading Multiple Relationships

А чем LIKE не устроил? У целом не очень понятна логика выделения именно отмеченных строк. Особенно в контексте "объединяет поле linkedID". На втором скрине они все разные.

Не стоит использовать localhost. Почему разбирается прямо на примере с MySQL: пример проблемы с localhost.

У вас видимо Materialized Path. С ходу нагуглил: Materialized Path в PostgreSQL

Составной ключ (индекс) нужен как и все индексы для ускорения выборки. Его можно не использовать и для каждого поля создать свой, но работать они будут медленее, чем составной и будет больше оверхеда на их поддержку.
Т.е. составной ключ нужен если у вас много выборок вида Поле1->Поле2->Поле3... При этом как уже отметил kilgur порядок полей имеет значение и работать будет быстро только префиксный вариант.

Нормальный вариант если у вас защита (шифрование канала) настроена. Если не настроена, то уже не принципиально что шлется. Код, хэш, соль... все будет перехватываемо и используемо.

Одна из причин по которой лично я перешел на Postgresql. Там есть RETURNING который может вернуть любое поле из вставленной строки, не только ID. Если нет ни каких специфичных кейсов использовать РСУБД, то переход получается простой.

Касательно контексте задачи. Предположу, что нужно фронту/клиенту получить идентификаторы вставляемых записей. Но решить указанную проблему можно зайдя с другой стороны. Идентификаторы генерировать на клиенте (т.е. условый ID записей известны уже ДО вставки в базу). В качестве такого идентификатора лучше использовать UUID реализация которого есть абсолютно во всех популярных языках.

Использую обе РСУБД. Предпочитаю Postgresql, хотя конечно начинал с MySQL. Из того, что на практике приводит к такому предпочтению:
1) Отсутствие проблем на по сути пустом месте. Из последнего было, в одной базе есть таблицы с большим количеством текстовых полей. При вставке в одно из них чуть меньше 200 символов он отказывался ссылаясь на то, что переводите на динамические. И я значит должен начать курить тему движков мускула и выяснять, что мне оказывается нужна Barracuda. При той же InnoDb. Хочется спросить такого черта.
Или вот еще вспомнил. При попытке записи в поле данных, больше чем это возможно для данной колонки он делает запись тупо обрезав лишнее. И проблему могут не заметить очень долго вплоть до момента когда подниматься из бэкапа поздно, там все уже битое.
Или вот взять и сменить могут дефолтные значение переменных в рамках минорной версии. База после накатки апдейтов и ребута может просто не подняться. На хабре даже была статься по этому поводу.
В общем множество подобных ситуаций после которых так и хочется воскликнуть "какого черта?!". Со слоном я не помню ни одной такой ситуации.
2) RETURN во вставках/обновлениях. Можно получить в ответе любое поле такого запроса. И ни каких тебе танцев с LastInsertId.
3) В последних версиях есть UPSERT которого очень не хватало.
4) В целом более строгий подход и нет ощущение бардака.
5) После запуска Postgres Pro появилась полностью руссифицированная документация. Помогает вкатиться в тему новичкам.

Из минусов некоторое время было отсутствие адекватного UI клиента. Но после того, как стал использовать PhpStorm эта проблема была закрыта.

Оставлю как ремарку для истории. На данный момент схема в sphinx получается самой быстрой. Вопрос с дельта индексом решился просто более частым его пересчетом. Теперь приложение следит за его размеров и как только в нем больше 20к документов, запускается ротирование. Получается требуемая быстрота выборки даже на сложных запросах.

Правильный вариант это Gettext. Стандарт которого уже много десяток лет. Под него огромная куча готово софта.

Пишите сразу md5 хэш в базу. По нему ставим индекс который и используем при поиске. Справиться ли сервер зависит от посещаемости, характеристик самого сервера, количестве данных в базе. Заполните базу фейковыми данными и посмотрите, сразу станет понятно.

Вторая таблица не нужна потому что не понятно, для чего она вообще нужна. А вот сделать механизм ротации этой таблицы однозначно стоит. Более чем достаточно, если в ней будут данные максимум за сутки.

В $HOME директории создаем файл .my.cnf (т.е. путь до него ~/.my.cnf) в который пишем название секции [client] и дальше реквизиты для соединения (кроме названия базы данных):

[alex@SUNDUKOV:~$] cat ~/.my.cnf 
[client]
user=root
password=root
host=localhost

Тогда можно соединяться указав только нужную для работы базу:

[alex@SUNDUKOV:~$] mysql test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1664475
Server version: 5.6.19-1~dotdeb.1 (Debian)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

Указанная логика фильтрации, это не фасетчатый фильтр. Объясняю на примере одежды. Фасетка это:
1) Пользователь в наборе фильтров выбрал размер Х одежды.
2) В связанных фильтрах, например цвет, скрылись (или стали неактивными) цвета для которых нет размера Х.

Первое с чего нужно начинать - смотреть логи. И что нам говорят логи?

А разве ни кого не смутило, что у автора первичный ключ составной и во WHERE используется вторая часть ключа?

@cookie по сути первичный ключ в данных запроса не работает.

mysqldump -uUSER -pPASSWORD -hlocalhost -d --default-character-set=utf8 --quote-names --allow-keywords --add-drop-table --set-charset schema_info > /path/to/file/schema.mysql

mysqldump -uUSER -pPASSWORD -hlocalhost -d --default-character-set=utf8 --quote-names --allow-keywords --add-drop-table --set-charset --ignore-table=schema_info > /path/to/file/schema.mysql

man mysqldump