







|
MySQL.RU - Webboard
Вернуться
ведение статистики и DATE TIME (Андрей) 29/08/2012 - 17:19:24
Re: ведение статистики и DATE TIME (Андрей) 29/08/2012 - 17:32:55
Re: ведение статистики и DATE TIME (Akina) 29/08/2012 - 18:19:16
Re: ведение статистики и DATE TIME (Андрей) 29/08/2012 - 18:45:39
Re: ведение статистики и DATE TIME (Akina) 29/08/2012 - 21:18:43
> Original message text:
> From: Андрей - 29/08/2012 - 17:19:24
> Subject:ведение статистики и DATE TIME
> -----------------
> Здравствуйте! хочу собирать статистику посещений сайта, создал базу:
> new_stat
>
> id int(5)
> code varchar(90)
> date date
> time time
> qstring varchar(255)
>
> Индексы
>
> code BTREE
> date BTREE
> time BTREE
>
> забил ее данными за пол года, примерно 3,5 млн записей
> и возникла проблема, при извлечении данных особенно требующих COUNT запрос выполняется довольно долго, например:
>
> SELECT COUNT(code) AS count, new_stat.id, users.name AS username, users.baseid, users.firm FROM `new_stat`
> LEFT JOIN users ON new_stat.id = users.id
> WHERE new_stat.date BETWEEN '2012-06-01' AND NOW() GROUP BY users.name ORDER BY count DESC LIMIT 0, 10
>
>
> время 5+ сек
>
> я уж молчу про длинные запросы когда требуется еще больше параметров, даже примитивный SELECT ..... GROUP BY code ORDER BY date, time тоже тормозит и время может доходить до 30+ сек.
>
> что я опять сделал не так?
> (З.Ы. а таблица каждый день все жирнее, через год будет вообще коллапс, добавил индекс BTREE для id - ситуация не улучшилась)
>
From: Akina - 29/08/2012 - 18:19:16
Subject:ведение статистики и DATE TIME
-----------------
Идея разделить дату и время на два поля - не самая разумная.
Идея хранить их в виде юникстайм в тексте - из той же бочки.
1) Объедини дату и время в рамках одного поля datetime;
2) Замени between на два неравенства (between не использует индекс - см. explain);
3) Понимай, что от filesort тебе всё равно никуда не деться;
4) Понимай, что при селективности new_stat.date BETWEEN '2012-06-01' AND NOW() более 20% индекс не будет использоваться никогда, а его форсаж только ухудшит ситуацию;
5) Оптимизируй запрос только по таблице new_stat, без подтягивания данных из второй таблицы. Скорее всего, лучше будет его оформить подзапросом, и лишь потом пришивать данные юзеров.
PS. Поле code - оно из таблицы new_stat?
[Это сообщение - спам!]
Последние сообщения из форума
Уважаемые посетители форума MySQL.RU!
Убедительная просьба, прежде чем задавать свой вопрос в этом форуме, обратите внимание на разделы:
- ответы на наиболее часто задаваемые вопросы - FAQ
- раздел документация
- раздел поиск по сообщениям форума и документации
Также, старайтесь наиболее подробно указывать свою ситуацию (версию операционной системы, версию MySQL,
версию программного обеспечения, по которому возникает вопрос, текст возникающих ошибок, и др.)
Помните, чем конкретнее Вы опишете ситуацию, тем больше шансов получить реальную помощь.
41635
|
|