|
Производительность запросов с Set
|
|||
---|---|---|---|
#18+
Делаю вычисления с пересечением множеств. Проходят вычисления по таблице, обновляются-добавляются-удаляются записи, в конце по этой же таблице надо смотреть какие записи не попали в обработку, и выдать по ним упоминания в лог ошибок. Делалось так: Идет обработка таблицы, ид обработанных записей заносятся в set (integer not null), под конец делается select id from maintable where id not in table(setvariable) - это выдает ид подвисших записей. Все бы хорошо, но выполнение конкретно этого запроса занимало десятки секунд. как я там ни изгалялся - ничего не помогало. Переделал на создание временной таблицы с одним полем с ид При обработке основной таблицы вместо сета идшники заносятся в эту таблицу, Для вычисления пересечения создаю вторую временную таблицу, в нее insert всех ид из основной таблицы, затем delete из нее where id in (select id from temptable1) Это - отрабатывает за доли секунды, хотя на первый взгляд работы серверу больше - во первых копируются ВСЕ ид основной таблицы, потом из нее удаляются ид обработанных записей... А работает быстро. Объясните почему такая хрень? Сервер 12.10fc6 Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 14:57 |
|
Производительность запросов с Set
|
|||
---|---|---|---|
#18+
falcon111, как насчёт мысли, что всё дело в индекса и оптимизаторе? В каком случае есть индексы и какие? Какие планы делает оптимизатор в обоих случаях? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2016, 11:29 |
|
Производительность запросов с Set
|
|||
---|---|---|---|
#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. 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. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68.
Вот результат: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Откуда такая разница? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 20:22 |
|
Производительность запросов с Set
|
|||
---|---|---|---|
#18+
falcon111, зуб даю, оптимизатор выдал разные планы запросов. В случае с временной таблицей вряд ли он делает 4000 поисков по ключу, но вот пересечение с индексом первичного ключа - запросто. А в случае с множеством - банальных 5000 переборов. Это и по времени видно... ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2016, 00:27 |
|
Производительность запросов с Set
|
|||
---|---|---|---|
#18+
АнатоЛой, То, что план разный строит, это очевидно, потом как смогу гляну план выполнения, я просто думал, может есть какие-то тонкости/рекомендации с использованием СЕТов... Апофеоз. В моем примере: Код: sql 1.
Это ^ выполняется полторы секунды. Код: sql 1.
А вот это ^ три сотых секунды. Если я не прав - объясните в чем, мне пока мыслится это косяком сервера. Радует только что причину непонятных тупняков я нашел. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2016, 01:40 |
|
Производительность запросов с Set
|
|||
---|---|---|---|
#18+
Рекомендация одна - стараться не использовать переменньіх для запросов в процедурах. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2016, 15:26 |
|
Производительность запросов с Set
|
|||
---|---|---|---|
#18+
Daugava, Надежда что в FC7 станет лучше не оправдалась. Все осталось как же, как было. Исключение только в том что все-таки результат с сетом стал оптимальным. Код: sql 1.
дает теперь 0.019s, 1000 recs Код: sql 1.
а это на треть медленнее: 0.030s, 1000 recs Для себя вопрос считаю исчерпанным. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2016, 18:57 |
|
|
start [/forum/topic.php?fid=44&tid=1606794]: |
0ms |
get settings: |
16ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
44ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
190ms |
get tp. blocked users: |
2ms |
others: | 367ms |
total: | 658ms |
0 / 0 |