Всё-таки наверное неправильно я сказал, по created_at лучше не групировать, а агрегировать:
1.
2.
3.
4.
5.
6.
7.
8.
SELECT t1.uid, MAX(t1.created_at) as created_at, COUNT(uid) AS count
FROM stats t1
WHERE t1.uid NOT IN (9421802727)
AND t1.ip NOT IN (3579284812)
GROUP BY t1.uid
HAVING DATEDIFF(MAX(t1.created_at), MIN(t1.created_at)) >= 21
ORDER BY count DESC
LIMIT 60
Но либо одно, либо другое надо сделать.
araman Но время выполнения все равно осталось прежним(~0,5сек).
Прикладываю индексы, теперь можно что то сделать или это уже "предел" для этой машины?
Смотрим ещё раз на запрос:
1.
2.
3.
4.
5.
6.
7.
8.
SELECT t1.uid, MAX(t1.created_at) as created_at, COUNT(uid) AS count
FROM stats t1
WHERE t1.uid NOT IN (9421802727) -- не SARG -- не оптимизитуется.
AND t1.ip NOT IN (3579284812) -- не SARG -- не оптимизитуется.
GROUP BY t1.uid -- оптимизитуется при наличии индекса с лидирующей t1.uid
HAVING DATEDIFF(MAX(t1.created_at), MIN(t1.created_at)) >= 21
ORDER BY count DESC
LIMIT 60
Итого -- запрос почти не оптимизируется, потому что обрабатывает
все записи из таблицы stats.
В плане в лучшем случае ты можешь избавится от сортировки (filesort).
Ещё раз хочу тебе предолжить:
создать справочник пользователей. Записей там будет существенно меньше (если сайт активный), чем в
добавить туда поля -- первый вход и последний вход.
выбирать запросом пользователей именно оттуда, а не из статистики.
