|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
У меня в процедуре есть много временных индексованных табличек с маленьким количеством записей. Индексы на них создаются сразу вместе с созданием таблиц. План который строится во время использования этих таблиц глючный: множит предпологаемое количество строчек и как результат: missing memory. Учитывая что основная табличка большая а количество джойнов с этими временными табличками тоже несколько, то результат получается астрономический. Особенно бесит что индексы все уникальные, т.е. кардиналити по отношению к главной таблице 1:1 по определению. Если строить (или престраивать) теже индексы НО не во время создания таблиц а после вноса данных- план корректный. Почему так несправедливо? SQL Server 2017 CU18 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 09:10 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Daba У меня в процедуре есть много временных индексованных табличек с маленьким количеством записей. Индексы на них создаются сразу вместе с созданием таблиц. План который строится во время использования этих таблиц глючный: множит предпологаемое количество строчек и как результат: missing memory. Учитывая что основная табличка большая а количество джойнов с этими временными табличками тоже несколько, то результат получается астрономический. Особенно бесит что индексы все уникальные, т.е. кардиналити по отношению к главной таблице 1:1 по определению. Если строить (или престраивать) теже индексы НО не во время создания таблиц а после вноса данных- план корректный. Почему так несправедливо? SQL Server 2017 CU18 Не хотите попробовать вместо временных таблиц использовать In-Memory SCHEMA_ONLY. Они очень хорошо заточены под LOOKUP ? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 09:16 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Daba Почему так несправедливо? Это же явно слишком дорого, производительность рухнет, выгоднее построить статистику один раз, при создании индекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 09:41 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
a_voronin, Я не очень в теме. Посмотрю. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 10:03 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Daba Особенно бесит что индексы все уникальные, т.е. кардиналити по отношению к главной таблице 1:1 по определению. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 10:06 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
alexeyvg, Согласно алгоритму должен перестраивать после вставки. А иначе как? Иначе в чём смысл статистики? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 10:15 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Daba a_voronin, Я не очень в теме. Посмотрю. https://www.sql.ru/forum/1301504/baza-s-tablicami-inmemory-dolgo-startuet https://www.sql.ru/forum/1216423/prevratnosti-administrirovaniya-sql-server Но фича интересная, полезно будет про неё узнать и попробовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 10:15 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Daba alexeyvg, Согласно алгоритму должен перестраивать после вставки. Там алгоритм совсем другой: https://docs.microsoft.com/ru-ru/sql/relational-databases/statistics/statistics?view=sql-server-ver15#when-to-update-statistics Оптимизатор запросов определяет, устарела ли статистика, а затем при необходимости обновляет ее, если она требуется для плана запроса. https://docs.microsoft.com/ru-ru/sql/t-sql/statements/alter-database-transact-sql-set-options?view=sql-server-ver15#auto_update_statistics AUTO_UPDATE_STATISTICS { ON | OFF } ON Указывает, что оптимизатор запросов обновляет статистику, если она используется в запросе и может оказаться устаревшей. Статистика становится устаревшей, после того как операции вставки, обновления, удаления или слияния изменяют распределение данных в таблице или индексированном представлении. Оптимизатор запросов определяет, когда статистика может оказаться устаревшей, подсчитывая операции изменения данных с момента последнего обновления статистики и сравнивая количество изменений с пороговым значением . Пороговое значение основано на количестве строк в таблице или индексированном представлении. Daba А иначе как? Иначе в чём смысл статистики? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 10:25 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Daba У меня в процедуре есть много временных индексованных табличек с маленьким количеством записей. Индексы на них создаются сразу вместе с созданием таблиц. План который строится во время использования этих таблиц глючный: множит предпологаемое количество строчек и как результат: missing memory. Учитывая что основная табличка большая а количество джойнов с этими временными табличками тоже несколько, то результат получается астрономический. Особенно бесит что индексы все уникальные, т.е. кардиналити по отношению к главной таблице 1:1 по определению. Вангую, что запрос кривой как турецкая сабля. Но нам его не покажут. Daba Если строить (или престраивать) теже индексы НО не во время создания таблиц а после вноса данных- план корректный. Откуда взять "статистику", если в таблице ничего нету? Можно заменить #table на @table - в таблицах-переменных для оптимизатора, по-умолчанию, 1-запись. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 11:04 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Если ситуация улучшается после принудительного обновления статистик, то почему бы не обновлять? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 11:10 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Daba, Если вам нужно пересчитать статистику после всех вставок в # таблицу, используйте update statistics ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 11:11 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
aleks222 Можно заменить #table на @table - в таблицах-переменных для оптимизатора, по-умолчанию, 1-запись. и для них даже можно индексы создавать https://www.sqlpassion.at/archive/2013/06/26/non-clustered-indexes-on-table-variables-in-sql-server-2014/ ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 14:18 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Можно конечно делать update statistics но это вообще не камильфо. Есть алгоритм как определяется или статистика "просрочена". Да, на самом деле пересчет происходит только перед запросом с аргументом по индексированному полю. Да, запрос не "песня" но и не страшный: большая темп табл с несколькими лефт джоинами маленьких темп таблиц, иногда с одной и тоже. Всё правда. Как это объясняет то что в одном случае план жёстко глючит а в другом, с построением индекса в конце, работает хорошо? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 14:29 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Daba Всё правда. Как это объясняет то что в одном случае план жёстко глючит а в другом, с построением индекса в конце, работает хорошо? UPD К тому же построение индекса благоприятно влияет на скорость вставки. Мне никогда не приходило в голову делать индекс на пустой временной таблице, как то это странно, неестественно. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 14:39 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Не припоминаю точно, но разве для временных таблиц статистика пересчитывается при вставке? ИМО это лишние накладные расходы. Здравый смысл подсказывает, что порядок действий должен быть таким - заполнил, проиндексировал, запросил. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 15:57 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Владислав Колосов что порядок действий должен быть таким - заполнил, проиндексировал, запросил. Если индекс уникальный, то его наличие до вставки гарантирует отсутствие дублей. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 17:02 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
msLex Владислав Колосов что порядок действий должен быть таким - заполнил, проиндексировал, запросил. Если индекс уникальный, то его наличие до вставки гарантирует отсутствие дублей. Т.е. это вопрос: "где получить ошибку, во время вставки, или во время создания индекса"; по моему, принципиальной разницы нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 17:48 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
alexeyvg, Создание индекса "инлайн" вовремя создания таблички, одним запросом, потенциально снижает нагрузку на метадату в tempdb. Ещё раз, всё что вы говорите правильно, но это всё workarounds. По мне так движок запросов просто глючит. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2020, 19:33 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Daba, откуда уверенность, что это не by design? Построение индекса "на лету" никогда не было быстрее построения индекса "по факту", насколько мне известно. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2020, 11:49 |
|
статистики на временных табличках
|
|||
---|---|---|---|
#18+
Daba По мне так движок запросов просто глючит. Так же написано в документации на продукт, откуда я приводил цитаты. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2020, 13:24 |
|
|
start [/forum/topic.php?fid=46&msg=39954525&tid=1686154]: |
0ms |
get settings: |
12ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
25ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
others: | 17ms |
total: | 148ms |
0 / 0 |