SELECT COUNT(`id`)
FROM `data`
WHERE `id` IN (
SELECT `id_data`
/ * JOIN несколько таблиц и т.п.*/
WHERE /* куча условий */
)
/* LIMIT 1000 */
Если проблема в том что мне надо перелопачивать миллионы записей с диска - ну как бы любая БД будет пыхтеть. То есть задача не должна быть - в выборе БД, а задача в том что бы он не 3 миллиона записей с диска тащил, а чуток поменьше
Стоит привести explain. Равно и какой порядок полей в составном индексе вы делали?
А почему одна сущность "категории" разбита по двум таблицам?
И оптимизация тут будет одна - отдельная таблица или вью (материализованное) которая пересчитывается или обновляется ровно под эти запросы. А пересчет изменений - там уж в зависимости от того как часто мы это дергаем - кроном, триггером.
Вымарывать названия таблиц - это конечно ржачный идиотизм. NDA, да?
1. Ну а по существу - ну вы из таблицы D я так понимаю выгребаете большую часть записей. Как бы ясень фиг что индекс не будет использоваться - смысл если вам все равно практически всю таблицу выдергивать. И оптимизации то тут какие могут быть если вы требуете от БД вытащить все записи из таблицы?
2. У вас там в нескольких местах mysql вам сообщает что ключей возможных несколько - может вам попробовать композитные индексы?
Ладно...попробую погуглить на эту тему...
Просто если просто выбирать записи без подсчёта, то по EXPLAIN результаты разные в зависимости от условий в WHERE (они динамические), но на все нужные поля есть индекс...но бывает так, что даже с учётом индекса бывает большой "скан" таблиц...
Поэтому вопрос больше был в стиле "выжать" максимум из самого MySQL исходя из этой структуры, как я описал...
Насчёт вопроса автора - всё верно...у него более статичные данные по условиям выборки...