История изменений
Исправление BaBL, (текущая версия) :
Так те же уши будут.
Не факт, они на innodb собаку давно жрут.
Я вижу в «медленной» констрейнт на «быструю», а в быстрой только на users. Учитывая что мы на колде тестируем - не может ли быть что он перед count перестраивает весь этот индекс (опять же, там каскад), грузит его в память и т.д., а уже потом быстро вам начинает все отдавать на горячем? Юзеров у вас вряд ли 4 ляма.
CONSTRAINT posts_cache_ibfk_1 FOREIGN KEY (id) REFERENCES posts (id) ON DELETE CASCADE ON UPDATE CASCADE
count([em])Я почему спрашиваю, если вы в count пихаете какое-то поле, то в верхней таблице у вас куча индексов по ним, а в нижней - нету.
Исходная версия BaBL, :
Так те же уши будут.
Не факт, они на innodb собаку давно жрут.
Я вижу в «медленной» констрейнт на «быструю», а в быстрой только на users. Учитывая что мы на колде тестируем - не может ли быть что он перед count перестраивает весь этот индекс (опять же, там каскад), грузит его в память и т.д., а уже потом быстро вам начинает все отдавать на горячем? Юзеров у вас вряд ли 4 ляма.
CONSTRAINT posts_cache_ibfk_1 FOREIGN KEY (id) REFERENCES posts (id) ON DELETE CASCADE ON UPDATE CASCADE
count() - это не ошибка? count(*) считает все строки, count(id) - те. в который id is not null, count(distinct id) - уникальные id. Они выполняются по разному и с разной скоростью.
Я почему спрашиваю, если вы в count пихаете какое-то поле, то в верхней таблице у вас куча индексов по ним, а в нижней - нету.