|
|
|
Упрощение тройного запроса.
|
|||
|---|---|---|---|
|
#18+
Есть таблица, в ней - ID, дата, количество просмотров, количество ответов. Есть задача - просуммировать для каждого ID просмотры и ответы за последние три дня. Поправка: дни - это не сегодня, вчера, позавчера, это - последние три записи. То есть сегодня могло не быть просмотров и ответов вообще, значит - запись не создалась, а значит берем вчера, позавчера, позапозавчера. Нам нужны именно "непустые" дни, поэтому вариант решения с созданием "нулевой" статистики и потом расчетом по сегодня, вчера и позавчера - не подходит. Получилось решить лишь таким запросом с несколькими уровнями вложенности: Код: sql 1. 2. 3. 4. 5. 6. 7. 1. Самый "глубокий", первый запрос: Код: sql 1. получает id, дату, просмотры и ответы, сортирует их так, чтобы id шли подряд, а у этих id - даты в порядке убывания (дата записана в формате '2014-03-01') 2. Второй запрос: Код: sql 1. Номерует следующие друг за другом строки. Благодаря тому, что по id у нас уже отсортировано, а даты идут по убыванию - мы получаем при смене id сброс переменной @num, а самые свежие данные (за последнюю дату) будут иметь число 1 в поле day 3. Внешний, третий запрос: Код: sql 1. Откидываем все то, что имеет поле day больше 3х (то есть получаем в остатке лишь последние три дня для каждого id) и уже группируем по id, суммируя количество просмотров и ответов. Именно такой запрос у меня получился после долгих попыток сообразить, как его сделать. Но в таком виде он, как минимум, пугающий, не говоря уже о скорости выполнения. Может кто помочь советом, как достичь цели лучшим образом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2014, 19:40:19 |
|
||
|
Упрощение тройного запроса.
|
|||
|---|---|---|---|
|
#18+
Demise, TOP-N query: 7489069 вопшемто у вас аналогичный подход Вот мой оригинальный СКЛ с комментариями Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Как я понимаю, это максимально быстрый вариант. Ограничения тут в размере памяти -- на достаточно больших размерах таблицы может начатся свап на диск. Конечно же надо оптимизировать индекс(ы) для скорости. Серьезным улучшением будет предрасчет (пре-агрегация) самого глубоково подселекта с созданием постоянной таблицы. Каждый день туда добавлять записи за предыдуший день. Другой вариант тойже идеи -- сделать триггер на инсерт в основную таблицы для апдейта пре-агрегатной таблицы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2014, 19:59:57 |
|
||
|
Упрощение тройного запроса.
|
|||
|---|---|---|---|
|
#18+
javajdbc, С памятью проблем нет, на сервере ее свободно еще порядка 80Гб. Так понимаю, что максимум - поковыряться в конфигах самого MySQL для оптимальной обработки таких запросов (в таблице их может быть около 2.000.000 - это с архивированием старых). Спасибо за ответ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2014, 20:39:22 |
|
||
|
|

start [/forum/topic.php?fid=47&fpage=180&tid=1834921]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
23ms |
get topic data: |
5ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 190ms |
| total: | 270ms |

| 0 / 0 |
