Задавайте вопросы, мы ответим
Вы не зашли.
Таблицы:
Неактивен
1. А почему Вы считаете, что 0.5 секунды - это медленно?
2. Потому что Выбирается 3232 строки из ss (по id_site и `DATE`) и к ним выбирается по 1 строке из sh
3. Потому что используется query cache
4. Потому что за другую дату строк меньше
5. Можете, например сделать отдельную статистическую табличку с количествами.
P.S.
Если названия табличек правильные, то вторая табличка по сути является индексатором "фраза в id"
и фраза в ней должна быть уникальной. Тогда логичным было бы в ней иметь уникальный ключик
на фразе. Тогда запрос будет выполняться "в обратную сторону", т.е. сначала выбираться id из sh,
а потом данные из ss (понадобится ключик на (id_phrase, DATE, id_site)).
Неактивен
paulus написал:
1. А почему Вы считаете, что 0.5 секунды - это медленно?
Потому что 100 таких запросов в секунду повесят сервер.
P.S. помог - и как я сам об этом не подумал.
Спасибо.
в итоге запрос:
SELECT COUNT(*) cnt
FROM stat_sessions ss
WHERE id_site = 3859145633108167829
AND ss.`date` IN ('20081112')
AND ss.`id_phrase` = 1184296430239181593
и выполняется безумно быстро - что и требовалось. Я рад.
Неактивен
А еще подвох был а том, что:
SELECT *
FROM `stat_phrases` s
WHERE s.`phrase` = 'московские окна'
Выдает много строк вместо 1й (придется приводить все к нижнему регистру):
id phrase
1184296430239181593 московские окна
1921506984546157405 Московские окна
313527517360681430 МОСКОВСКИЕ ОКНА
4113086964125427273 Московские Окна
1658956355332919903 Московские ОКНА
4216182914979148941 МОсковские окна
2910815411339435350 мОсковские окна
4969293543036981317 московские Окна
1709261834205483246 мОСКОВСКИЕ ОКНА
Неактивен
Если уже существующие данные - то да, а вообще хорошо бы иметь ci-сопоставление, тогда
оно будет не чувствительно к регистру.
Неактивен