Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
Всем привет! Дано: таблица очереди заявок Код: 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. 27. Из этой выборки выполняется выборка в порядке приоретизации, что выливается в SELECT... ORDER BY. Количество и порядок ключей сортировки настраивается. Большинство параметров приоретизации вполне тривиальны: просто добавляется поле из APPLICATION_IDX. Но есть несколько кейсов, приводящих к вычисляемым выражениям, что препятствует использованию индекса. 1. Отложенная заявка с наступившим временем Приводит к такому выражению Код: sql 1. 2. Последний оператор Код: sql 1. 3. Время для звонка да/нет Какая тут кляуза вообще пока не знаю. Видимо, надо добавить 2 столбца START_DIAL_TIME типа TIME и END_DIAL_TIME. При попадание в него значение ключа = 1, иначе 0. Существует ли способ оптимизировать такие ORDER BY? ВЫборка будет или постраничная, или 1 запись, идущая первой в очереди. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2018, 07:34 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
WGA1. Отложенная заявка с наступившим временем Приводит к такому выражению Код: sql 1. 2. Последний оператор Код: sql 1. 3. Время для звонка да/нет Какая тут кляуза вообще пока не знаю. Видимо, надо добавить 2 столбца START_DIAL_TIME типа TIME и END_DIAL_TIME. При попадание в него значение ключа = 1, иначе 0. Существует ли способ оптимизировать такие ORDER BY? ВЫборка будет или постраничная, или 1 запись, идущая первой в очереди.Первую сортировку можно заменить на order by APPLICATION_IDX.SUSPEND_TIME А вот с второй и третьей непонятно, видимо, никак не оптимизировать В общем случае, вычисляемые сортировки либо нужно оптимизировать, как в (1), либо предварительно рассчитывать (менять схему данных), либо вообще никак, если выражения недетерминированы (случай 2) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2018, 09:14 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
WGAКоличество и порядок ключей сортировки настраивается.При таком подходе, для оптимизации сортировки, т.е. ее физического исключения из плана выполнения, на каждый вариант порядка нужен свой индекс с секцией include, содержащей все остальные столбцы, используемые в запросе. У вас сделано именно так? При наличии сортировки по вычисляемым столбцам, зависимым от внешних данных, избавиться от физической сортировки невозможно. Или для вас "оптимизация сортировки" нечто другое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2018, 10:42 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
alexeyvgлибо вообще никак, если выражения недетерминированы (случай 2) Да ладно те union all спасет Код: sql 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2018, 16:56 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
aleks222alexeyvgлибо вообще никак, если выражения недетерминированы (случай 2) Да ладно те union all спасет Код: sql 1. 2. 3. У меня мелькнула мысль, но это же на практике неприменимо. Во первых, если таких "особых" сортировок больше одной, то union all получится слишком много, для всех комбинаций. Во вторых, автор использует сортировку для постраничного вывода, и получится в итоге 2 больших наборов данных, которые нужно потом слить и отсортировать, на этот раз вообще без индексов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2018, 17:36 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
aleks222union all спасет Код: sql 1. 2. 3. Каким образом, если выражение не первое в списке? А если первое, то чем гарантирован порядок строк в результирующем наборе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2018, 18:52 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
Я думаю, что это задача прикладного уровня и должна решаться приложением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 11:24 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовЯ думаю, что это задача прикладного уровня и должна решаться приложением.Постраничная выборка или выборка одной строки согласно разнообразным критериям сортировки? ЗЫ: Некоторое время назад тут был один кадр, утверждавший, что джойнить таблицы в приложении гораздо выгоднее. Думается мне, вы, в своей страсти низвести сервер СУБД до простого хранилища таблиц, скоро достигнете его уровня... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 11:43 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
invm, не совсем так, я моем представлении здесь требуется динамический тоссинг заявок, а это выгоднее обрабатывать в памяти массивами данных. Т.е. в заявках приоритеты непрерывно изменяются, причем для каждого оператора индивидуально. Логично представить работу с индивидуально загруженными массивами данных и перерасчету приоритетов по таймеру, например. Т.е. робот рассчитывает приоритеты, интерфейс отображает и т.д. Задача комплексная, нельзя ее пытаться решить чисто средствами SQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 12:13 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
invmaleks222union all спасет Код: sql 1. 2. 3. Каким образом, если выражение не первое в списке? А если первое, то чем гарантирован порядок строк в результирующем наборе?Идея видимо такая, что двумя запросами выбираются нужные записи, и в соотв запросах ставится поле типа is_current_user 0 или 1, а потом делается сортировка по нему. Для компактного результата действительно хороший вариант, позволяет использовать индекс по LAST_USER_ID, но для постраничной выборки не сработает. ЗЫ Можно конечно сказать, что для компактного результата это не нужно, потому что вычисляемое выражение будет вычисляться по небольшому количеству записей. Но тут есть тонкость - для реализации очередей такое не сработает. Допустим, мы должны выбирать для обработки каждый раз по 10 записей, из огромной таблицы Тогда будет сортировка без индекса по большому объёму А вот если сделать union all 2х запросов по 10 записей, и потом взять 10 из полученного набора (из максимум 20 записей), то получится быстрый запрос, использующий индексы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 12:33 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
Владислав Колосовздесь требуется динамический тоссинг заявок, а это выгоднее обрабатывать в памяти массивами данных.Это выгоднее обрабатывать средствами, предназначенными для манипулирования множествами, т.е. на стороне СУБД. Приложение должно получать готовый результат, а не лопатить сырые данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 12:40 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
alexeyvgИдея видимо такая, что двумя запросами выбираются нужные записи, и в соотв запросах ставится поле типа is_current_user 0 или 1, а потом делается сортировка по нему.Результат объединения все равно придется сортировать по всем критериям, а не только по этому признаку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 12:49 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
invmalexeyvgИдея видимо такая, что двумя запросами выбираются нужные записи, и в соотв запросах ставится поле типа is_current_user 0 или 1, а потом делается сортировка по нему.Результат объединения все равно придется сортировать по всем критериям, а не только по этому признаку.Да, по всем критериям, и что это меняет в моих рассуждениях? "А потом делается сортировка по нему" - имеется в виду, что при сортировке по всем критериям потом будет использоваться is_current_user вместо case. То есть вместо Код: sql 1. 2. будет Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. А для работы с очередью Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 13:39 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
invmВладислав Колосовздесь требуется динамический тоссинг заявок, а это выгоднее обрабатывать в памяти массивами данных.Это выгоднее обрабатывать средствами, предназначенными для манипулирования множествами, т.е. на стороне СУБД. Приложение должно получать готовый результат, а не лопатить сырые данные. Не факт, если речь идет о персонифицированных наборах данных. Предварительные выборки да, выгоднее производить на сервере, но сортировки, фильтры и разметку в условиях, приближенных к реал-тайм - локально, вместо того, чтобы спамить крупные запросы и обновления на сервере от множественных пользователей каждые N секунд. С сервера же выгодно забирать небольшие порции свежих данных. Но, я вижу, у Вас стойкая позиция относительно архитектуры приложения подобного рода :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 14:04 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
alexeyvgТо есть вместо Код: sql 1. 2. будет Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. Сравним Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. Код: plaintext 1. 2. 3. 4. 5. Далеко не факт, что в реальной задаче ТС будет возможно задействовать индекс по LAST_USER_ID. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 14:11 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовНо, я вижу, у Вас стойкая позиция относительно архитектуры приложения подобного рода :)У вас не менее стойкая :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 14:12 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
WGA, Мне кажется, что вы пытаетесь решить не совсем ту задачу, которую вам нужно решить; что вам нужна не единая абсолютная реал-тайм приоретизация, а взаимозависимые очереди звонков для операторов. К вашему решению будут приходить запросы типа "выдай наиболее приоритетный звонок для указанного оператора (или группы, в т.ч. Все операторы) на текущее время, если такового нет - передай чей-то наименее приоритетный" и "измени приоритет звонка согласно изменению заявки". А это уже прямо описывает структуру данных таблицы Очередь: Оператор (группа), Временной диапазон (подробности опускаю), Приоритет, Заявка. Индекс по первым трем полям (1-2-3 или 1-3-2), индекс по заявке. Можно секционировать по оператору. При направлении заявки на обзвон в очереди создается 1...n записей. При взятии оператором в обработку n-1 записей удаляются. При модификации заявки (в т.ч. после звонка оператора) все записи по заявке удаляются и (при необходимости дальнейшего обзвона) создаются заново. Вставка заявки в середину очереди приоритета может осуществляться апдейтом приоритета конца очереди, пересозданием очереди или небольшими ухищрениями. Повторюсь: это то, что мне показалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 15:38 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
invmСравним ... И это "тепличный" пример. Далеко не факт, что в реальной задаче ТС будет возможно задействовать индекс по LAST_USER_ID.Я же написал, почему этот вариант не сработает, в ответе aleks222. Вы, по моему, прочитали одну фразу, и на неё отвечаете, а там было про несколько вариантов :-) Единственное практическое применение описанного aleks222 подхода использования индекса получается, в итоге, только работа с очередью. И вот тут будет фантастический выигрыш: для очереди Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. SQL Server Execution Times: CPU time = 984 ms, elapsed time = 994 ms. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 23:41 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовНе факт, если речь идет о персонифицированных наборах данных. Предварительные выборки да, выгоднее производить на сервере, но сортировки, фильтры и разметку в условиях, приближенных к реал-тайм - локально, вместо того, чтобы спамить крупные запросы и обновления на сервере от множественных пользователей каждые N секунд. С сервера же выгодно забирать небольшие порции свежих данных. Но, я вижу, у Вас стойкая позиция относительно архитектуры приложения подобного рода :)Я тоже не понимаю вашего неприятия обработки данных на платформе обработки данных. Почему приложение "СУБД" нельзя заспамить крупными запросами и обновлениями от множественных пользователей каждые N секунд, а собственноручно написанный сервер можно, откуда уверенность, что вы напишете обработку запросов лучше, чем команда разработчиков сервера? Я понимаю, что то, отличное от стандартной обработки данных, типа расчётов, всяких биткгойнов и шифрований, для этого РСУБД действительно не затачивалась, но писать свой сервер для стандартной обработки данных, типа реляционных операций или работы с очередями? От многих слышал, что так правильно, но не могу этого понять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 23:49 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
alexeyvgИ вот тут будет фантастический выигрышДа, но с не верным результатом. Вы отсортировать забыли Код: sql 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2018, 10:52 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
invmalexeyvgИ вот тут будет фантастический выигрышДа, но с не верным результатом. Вы отсортировать забыли Код: sql 1. 2. 3. Ой, действительно, забыл С сортировкой тот же результат (конечно, добавил индекс на v) С чего бы результату измениться, ведь в первом запросе сервер должен отсортировать все записи, а во втором - взять топ по индексу? сортировка Код: 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2018, 19:28 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
alexeyvgконечно, добавил индекс на vНу так вариант с индексом очевиден, но, видимо, далек от реальности ТС. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2018, 19:52 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
invmalexeyvgконечно, добавил индекс на vНу так вариант с индексом очевиден, но, видимо, далек от реальности ТС.Почему далёк? У ТС вопрос, как обеспечить быструю сортировку по выражению, для страничного вывода и организации очередей. Без всяких условий, типа "индексов не создавать". Можно создавать индексы, переписывать выражение, что угодно. Вплоть до полного изменения модели данных. Вот, для его первого выражение решение очевидно, просто, видно, у ТС глаз замылился - нужно просто сортировать не по выражению, а по по дате, результат тот же. Понятно, что быстро будет, если опять же сделать индекс по этой дате. А второе выражение так просто не заменишь, вот, можно на union all, с созданием индекса, но это поможет только для очередей, постраничная выборка будет медленной, какие бы индексы не делать. Но для рочереди это работает, притом что никакие индексы не помогут для первоначального запроса с сортировкой по case ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2018, 21:00 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
alexeyvgПочему далёк?Я исхожу из "Количество и порядок ключей сортировки настраивается". И не известно где будет среди этого перечня вычисляемый столбец. И сколько этих вычисляемых столбцов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2018, 21:40 |
|
||
|
Эффективный ORDER BY по вычисляемым выражениям
|
|||
|---|---|---|---|
|
#18+
invmalexeyvgПочему далёк?Я исхожу из "Количество и порядок ключей сортировки настраивается". И не известно где будет среди этого перечня вычисляемый столбец. И сколько этих вычисляемых столбцов.В таком случае подбирают индексы под типовые запросы, собирая статистику (логи) по ним. Как же иначе? Иначе любая сортировка, в такой постановке, сортировка всей выборки в памяти, тогда вообще не имеет смысла что то там менять, смотреть планы, оптимизировать, хоть для сортировки по выражениям, хоть по полям. То есть тогда вопрос ТС вообще не имеет смысла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2018, 16:47 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39716308&tid=1688972]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
32ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 265ms |
| total: | 397ms |

| 0 / 0 |
