Простое открытие, которым однако хочется поделиться...

Нельзя использовать CURRENT_DATE, CURRENT_TIME и CURRENT_TIMESTAMP в mySQL-запросах, которые генерируются из серверных скриптов типа PHP (или Perl, или что угодно). Нельзя, потому что CURRENT_DATE и CURRENT_TIME — вычисляемые при каждом запросе значения, из-за которого mySQL-выборка не будет закеширована.

Вместо CURRENT_DATE везде нужно использовать ".date('Y-m-d').", что положит в запрос константу, которая сделает запрос невычисляемым, легко кешируемым и переиспользуемым.

К примеру, у вас есть запрос, в котором помимо сложной, но хорошо проиндексированной выборки попадается условие «за последнюю неделю», типа something.time>DATE_SUB(CURRENT_DATE, INTERVAL 1 WEEK). Так вот использование CURRENT_DATE сведёт на нет все усилия по оптимизации. Нужно юзать только something.time>DATE_SUB("'.date('Y-m-d').'", INTERVAL 1 WEEK).

Век живи — век учись, короче...

UPD. Я себе сделал глобальную переменную (константу) $sqlday, в которую на этапе подключения скрипта к базе пишу '"'.date('Y-m-d').'"'. Везде всё подчистил, поубирал CURDATE, CURRENT_DATE, CURRENT_TIME и CURRENT_TIMESTAMP изо всех SELECT'ов, включая триггеры... И шо сказать, сайт заработал гораздо быстрее! Но это по субъективным ощущениям, точно не измерял.

UPD. Выборки по времени -- это наверно самая ресурсозатратная операция. Необходимо избегать выборок по времени как только это возможно. Можно наделать кучу костылей типа, автофлажков "recently_used" ENUM(Y/N), в которые пишется Y в триггере on_before_update, при любом использовании записи, и значения которых автоматически приводятся в точное соответствие один раз в сутки по планировку задач (встроенному шедуллеру).