|
|
|
Обойтись без объединения таблиц
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток! Никак не могу решить следующую задачу: Имеется таблица событий (полученная запросом), имеющая чуть более 600к записей такого вида triggeridtimevalue46397 2015-02-20 11:23:21 046397 2015-02-20 11:11:22 146397 2015-02-12 10:35:21 047654 2015-02-20 11:23:48 047654 2015-02-20 11:10:48 147654 2015-02-15 12:15:48 0 Нужно для каждого значения time, принадлежащего определенному triggerid, найти время следующего события, т.е. минимальное время из больших данного для данного triggerid. Нужно получить слеюующую таблицу: triggeridtimevaluenexttime46397 2015-02-20 11:23:21 0 null46397 2015-02-20 11:11:22 12015-02-20 11:23:2146397 2015-02-12 10:35:21 0 2015-02-20 11:11:2247654 2015-02-20 11:23:48 0 null47654 2015-02-20 11:10:48 12015-02-20 11:23:4847654 2015-02-15 12:15:48 02015-02-20 11:10:48 Такие задачи обычно решаются через join, что я, собственно, и сделал. Работает отлично, если я в запросе укажу небольшое кол-во triggerid. Но вот если не ограничивать запрос по их кол-ву, то запрос зависает, т.е. по графику утилизации процессора сервера БД видно, что БД ничего не выводит, просто забивает процессор. И это, в принципе, логично, он из-за join'а делает таблицу 600к х 600к строк. Может можно реализовать как-то эту задачу не прибегая к join? Или просто как-то модернизировать код? Код: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Вот этот join: Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2015, 17:39:41 |
|
||
|
Обойтись без объединения таблиц
|
|||
|---|---|---|---|
|
#18+
Попробовал реализовать через функцию: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Соответственно, в предыдущем коде изменил селект: Код: sql 1. 2. 3. 4. 5. По моим подсчетам, на одну запись уходит примерно 1-1,5 сек. Учитывая, что записей больше 600к, нужно еще быстрее... Кто-нибудь поможет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2015, 20:14:00 |
|
||
|
Обойтись без объединения таблиц
|
|||
|---|---|---|---|
|
#18+
Такую задачу нужно решать через пользовательские переменные. Это как раз оправданный случай их применения. Посмотрите эту статью . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2015, 20:27:05 |
|
||
|
Обойтись без объединения таблиц
|
|||
|---|---|---|---|
|
#18+
Pim., Может, изначально условия поменять? Обычно геморр с реализацией бывает из-за кривых входных параметров. Скажем, попробовать настроить железки на запись прямо в базу, либо таки добавить в файлы id, чтобы они и его писали. Следующий вариант - загрузил файлы, допустим, там у тебя 1000000 записей. Но железкам-то твоим похрен, в какой файл писать, верно? Значит, если ты сам лично в этот файл добавишь колонку id - то сможешь плясать от нее. Смотри, вот у тебя было: CoolRecords.txt Up at 12-12-2014 Down at 14-12-2014 Я тебе предлагаю самому переписать этот файл. Станет так: LOADED Up at 12-12-2014 LOADED Down at 14-12-2014 Теперь твои железки снова туда пишут. Получаешь ты файл такой: CoolRecords.txt LOADED Up at 12-12-2014 LOADED Down at 14-12-2014 Up 01-03-2015 И далее грузишь только те записи, у которых нет признака LOADED. Еще лучше, конечно, туда не LOADED, а дату-время загрузки писать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2015, 20:28:12 |
|
||
|
Обойтись без объединения таблиц
|
|||
|---|---|---|---|
|
#18+
Сорри, не туда вообще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2015, 20:31:29 |
|
||
|
Обойтись без объединения таблиц
|
|||
|---|---|---|---|
|
#18+
retvizan, Спасибо. Почитаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2015, 20:33:51 |
|
||
|
Обойтись без объединения таблиц
|
|||
|---|---|---|---|
|
#18+
retvizanТакую задачу нужно решать через пользовательские переменные. Это как раз оправданный случай их применения. Посмотрите эту статью . Спасибо! Это то, что надо. Только вот я не очень с этой темой разобрался. Не мог бы кто-нибудь помочь придумать запрос с использованием пользовательский переменных в рамках данной задачи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2015, 22:56:30 |
|
||
|
Обойтись без объединения таблиц
|
|||
|---|---|---|---|
|
#18+
retvizanТакую задачу нужно решать через пользовательские переменные. Это как раз оправданный случай их применения. Посмотрите эту статью . Спасибо Вам огромное! Я думал, у меня никогда не получится это сделать. 3 дня бился головой об стол... Итоговый код: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2015, 01:10:36 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38891800&tid=1833514]: |
0ms |
get settings: |
5ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
46ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 200ms |
| total: | 325ms |

| 0 / 0 |
