Если проблема в том что мне надо перелопачивать миллионы записей с диска - ну как бы любая БД будет пыхтеть. То есть задача не должна быть - в выборе БД, а задача в том что бы он не 3 миллиона записей с диска тащил, а чуток поменьше
Стоит привести explain. Равно и какой порядок полей в составном индексе вы делали?
А почему одна сущность "категории" разбита по двум таблицам?
И оптимизация тут будет одна - отдельная таблица или вью (материализованное) которая пересчитывается или обновляется ровно под эти запросы. А пересчет изменений - там уж в зависимости от того как часто мы это дергаем - кроном, триггером.
Вымарывать названия таблиц - это конечно ржачный идиотизм. NDA, да?
1. Ну а по существу - ну вы из таблицы D я так понимаю выгребаете большую часть записей. Как бы ясень фиг что индекс не будет использоваться - смысл если вам все равно практически всю таблицу выдергивать. И оптимизации то тут какие могут быть если вы требуете от БД вытащить все записи из таблицы?
2. У вас там в нескольких местах mysql вам сообщает что ключей возможных несколько - может вам попробовать композитные индексы?
Количество записей у вас такое что не должно быть проблем с общепринятым подходом.
Стоит ли разрываться между изучением программирования и подготовкой к ЕГЭ?