|
Оценка стоимости плана при смене уровня совместимости
|
|||
---|---|---|---|
#18+
Коллеги, добрый день. Давно перешли на версию mssql 2016 c 2008. Но до сих пор на части баз не поднят уровень совместимости из-за большого кол-ва кода, который при тестовом поднятии сразу начал тормозить. Цель поднятия уровня совместимости - использование новых возможностей свежих версий mssql. Вот исследую на примере одной хранимки, состоящей из одного запроса. При уровне совместимости 100(2008) в запросе данные выбираются по существующему индексу: 2 поля в индексе и все остальные в include. При переключении на уровень 130(2016) в плане уже скан таблицы. Пробовал включать LEGACY_CARDINALITY_ESTIMATION ON - это не влияет на запрос, все равно скан. Почему? Разве это не включение старой оценки? После уже заметил, что в таблице появилось еще одно поле, которое не входит в include. Поэтому при явном указании индекса или уровне совместимости 100, помимо поиска по индексу еще идет поиск ключа, т.е. еще одна операция. Суммарная предполагаемая стоимость 2 операторов выше, чем одного скана. Но при этом скорость выполнения отличается в десятки раз: скан 5-7мин против поиска по индексу 4-5с. Статистику по таблице обновлял. Как исправить конкретно этот запрос(явно указав нужный индекс) я знаю. + Планирую переделать индекс и включить недостающее поле в include. Но хранимок очень много. Как-то возможно решить вопрос поднятия уровня совместимости с сохранением старой оценки стоимости, без переделки кода и явного указания нужного индекса в запросах? Буду благодарен за наводку, куда копать. --- Проходя мимо разложенных граблей, ты теряешь драгоценный опыт. (с) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 17:07 |
|
Оценка стоимости плана при смене уровня совместимости
|
|||
---|---|---|---|
#18+
Megabyte Суммарная предполагаемая стоимость 2 операторов выше, чем одного скана. Но при этом скорость выполнения отличается в десятки раз: скан 5-7мин против поиска по индексу 4-5с. ну так значит таблица здоровая (скан 5-7мин), а запрос отбирает лишь небольшую часть строк(поиск по индексу 4-5с). и вот "старая" оценка и предполагала небольшое число строк, а по новой оценке выбирается слишком много. не индекс хинтом надо прописывать, а свои условия нормально переписать. наверняка туча OR. актуальный план чего жмотите, стыдно? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 17:46 |
|
Оценка стоимости плана при смене уровня совместимости
|
|||
---|---|---|---|
#18+
Yasha123 Megabyte Суммарная предполагаемая стоимость 2 операторов выше, чем одного скана. Но при этом скорость выполнения отличается в десятки раз: скан 5-7мин против поиска по индексу 4-5с. ну так значит таблица здоровая (скан 5-7мин), а запрос отбирает лишь небольшую часть строк(поиск по индексу 4-5с). и вот "старая" оценка и предполагала небольшое число строк, а по новой оценке выбирается слишком много. не индекс хинтом надо прописывать, а свои условия нормально переписать. наверняка туча OR. актуальный план чего жмотите, стыдно? Не стыдно вообще, ибо не я автор, это раз. :) Но в любом случае запрос линейный, без единого OR. Так что догадка не верна. Переписывать там особо нечего. Таблица здоровая, да. Но выборка по индексу быстрая. Да вот собсно запрос: Код: 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. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95.
report..LS - большая таблица данных, к нему джойнятся различные мелкие справочники. Spr_CallResult - тоже небольшой справочник. Report.dbo.BreakDialByUserNew - таблица данных, но сильно меньше объемом, чем report..LS. Ну разве что пару outer apply можно переписать. Но я не стал копаться, т.к. запрос работает приемлемое время. p.s. Попытался сохранить xml-план в файл и прикрепить, получился файл большего размера(234кб), чем можно прикрепить(150кб). ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 18:21 |
|
Оценка стоимости плана при смене уровня совместимости
|
|||
---|---|---|---|
#18+
Megabyte p.s. Попытался сохранить xml-план в файл и прикрепить, получился файл большего размера(234кб), чем можно прикрепить(150кб). можно воспользоваться сервисом Paste The Plan или просто заархивировать в zip ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 18:34 |
|
Оценка стоимости плана при смене уровня совместимости
|
|||
---|---|---|---|
#18+
а чего молчали про параметры? Код: sql 1.
это же процедура, а не запрос с переменными, как вы сейчас показываете. а процедура как прослушала разок параметры, так и план вы получили соответствующий. если в первый запуск интервал времени [@sd, @ed] был небольшой, то в плане индекс и лукапы, а если пардон весь период, какой только есть в таблице, то и будет скан. и если теперь во второй раз пустить эту же сп с другими параметрами, то тормоза и будут. припишите запросу в sp option(recompile) в самый конец, проверьте ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 18:44 |
|
Оценка стоимости плана при смене уровня совместимости
|
|||
---|---|---|---|
#18+
Megabyte При уровне совместимости 100(2008) в запросе данные выбираются по существующему индексу: 2 поля в индексе и все остальные в include. При переключении на уровень 130(2016) в плане уже скан таблицы. Пробовал включать LEGACY_CARDINALITY_ESTIMATION ON - это не влияет на запрос, все равно скан. Почему? после выполнения alter database .. set compatibility_level все планы этой базы в кэше инвалидируются. видимо после этого кто-то запустил сп с параметрами, где скан был выгоднее. потом запустили вы, уже с параметрами, где выгоднее индекс и лукапы. что делает с планами LEGACY_CARDINALITY_ESTIMATION ON надо проверять, мне не приходилось использовать, но даже если и это выносит все планы, видимо снова кто-то успел запустить сп с параметрами, провоцирующими скан. не можете прикрепить план, посмотрите для каких параметров он был скомпилирован ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 19:01 |
|
Оценка стоимости плана при смене уровня совместимости
|
|||
---|---|---|---|
#18+
Yasha123 а чего молчали про параметры? Код: sql 1.
это же процедура, а не запрос с переменными, как вы сейчас показываете. а процедура как прослушала разок параметры, так и план вы получили соответствующий. если в первый запуск интервал времени [@sd, @ed] был небольшой, то в плане индекс и лукапы, а если пардон весь период, какой только есть в таблице, то и будет скан. и если теперь во второй раз пустить эту же сп с другими параметрами, то тормоза и будут. припишите запросу в sp option(recompile) в самый конец, проверьте Да, изначально это хп. Выдал запрос, не подумал, что надо сказать про хранимку. В таблице данные за несколько месяцев, а выборка за 1 день. Если бы выбирался почти весь период, то вопросов бы про скан не было. :) Про "option(recompile)" - спасибо, попробую. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 10:03 |
|
|
start [/forum/topic.php?fid=46&fpage=45&tid=1685526]: |
0ms |
get settings: |
12ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
71ms |
get tp. blocked users: |
3ms |
others: | 300ms |
total: | 465ms |
0 / 0 |