Гость
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / статистики на временных табличках / 21 сообщений из 21, страница 1 из 1
06.05.2020, 09:10
    #39954484
Daba
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
У меня в процедуре есть много временных индексованных табличек с маленьким количеством записей.
Индексы на них создаются сразу вместе с созданием таблиц. План который строится во время использования этих таблиц глючный: множит предпологаемое количество строчек и как результат: missing memory. Учитывая что основная табличка большая а количество джойнов с этими временными табличками тоже несколько, то результат получается астрономический. Особенно бесит что индексы все уникальные, т.е. кардиналити по отношению к главной таблице 1:1 по определению.
Если строить (или престраивать) теже индексы НО не во время создания таблиц а после вноса данных- план корректный.
Почему так несправедливо?

SQL Server 2017 CU18
...
Рейтинг: 0 / 0
06.05.2020, 09:16
    #39954487
a_voronin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Daba
У меня в процедуре есть много временных индексованных табличек с маленьким количеством записей.
Индексы на них создаются сразу вместе с созданием таблиц. План который строится во время использования этих таблиц глючный: множит предпологаемое количество строчек и как результат: missing memory. Учитывая что основная табличка большая а количество джойнов с этими временными табличками тоже несколько, то результат получается астрономический. Особенно бесит что индексы все уникальные, т.е. кардиналити по отношению к главной таблице 1:1 по определению.
Если строить (или престраивать) теже индексы НО не во время создания таблиц а после вноса данных- план корректный.
Почему так несправедливо?

SQL Server 2017 CU18


Не хотите попробовать вместо временных таблиц использовать In-Memory SCHEMA_ONLY. Они очень хорошо заточены под LOOKUP ?
...
Рейтинг: 0 / 0
06.05.2020, 09:41
    #39954491
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Daba
Почему так несправедливо?
А как сервер мог бы делать это оптимальнее, перестраивать статистику после вставки каждой записи?

Это же явно слишком дорого, производительность рухнет, выгоднее построить статистику один раз, при создании индекса.
...
Рейтинг: 0 / 0
06.05.2020, 10:03
    #39954494
Daba
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
a_voronin,

Я не очень в теме. Посмотрю.
...
Рейтинг: 0 / 0
06.05.2020, 10:06
    #39954495
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Daba
Особенно бесит что индексы все уникальные, т.е. кардиналити по отношению к главной таблице 1:1 по определению.
Интересно, а если вместо индексов делать unique констрейны, что то изменится?
...
Рейтинг: 0 / 0
06.05.2020, 10:15
    #39954499
Daba
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
alexeyvg,

Согласно алгоритму должен перестраивать после вставки. А иначе как? Иначе в чём смысл статистики?
...
Рейтинг: 0 / 0
06.05.2020, 10:15
    #39954500
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Daba
a_voronin,

Я не очень в теме. Посмотрю.
Я бы не стал использовать InMemory только лишь из за неправильной статистики на временной таблице :-)
https://www.sql.ru/forum/1301504/baza-s-tablicami-inmemory-dolgo-startuet
https://www.sql.ru/forum/1216423/prevratnosti-administrirovaniya-sql-server

Но фича интересная, полезно будет про неё узнать и попробовать.
...
Рейтинг: 0 / 0
06.05.2020, 10:25
    #39954504
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Daba
alexeyvg,

Согласно алгоритму должен перестраивать после вставки.
Ээээ, согласно какому алгоритму? Тому, который описан в документации MSSQL?

Там алгоритм совсем другой:
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
А иначе как? Иначе в чём смысл статистики?
Пересчитывать статистику после каждой вставки абсурдно; вы представляете, насколько велика разница стоимости между добавлением строки в свободный слот на странице, и сканированием всей таблицы, или сэмпла, с подсчётом распределения значений? Вставлять строки можно много тысяч раз в секунду, а пересчитывать статистику так быстро нельзя.
...
Рейтинг: 0 / 0
06.05.2020, 11:04
    #39954518
aleks222
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Daba
У меня в процедуре есть много временных индексованных табличек с маленьким количеством записей.
Индексы на них создаются сразу вместе с созданием таблиц. План который строится во время использования этих таблиц глючный: множит предпологаемое количество строчек и как результат: missing memory. Учитывая что основная табличка большая а количество джойнов с этими временными табличками тоже несколько, то результат получается астрономический. Особенно бесит что индексы все уникальные, т.е. кардиналити по отношению к главной таблице 1:1 по определению.


Вангую, что запрос кривой как турецкая сабля.
Но нам его не покажут.

Daba

Если строить (или престраивать) теже индексы НО не во время создания таблиц а после вноса данных- план корректный.

Откуда взять "статистику", если в таблице ничего нету?
Можно заменить #table на @table - в таблицах-переменных для оптимизатора, по-умолчанию, 1-запись.
...
Рейтинг: 0 / 0
06.05.2020, 11:10
    #39954522
Владислав Колосов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Если ситуация улучшается после принудительного обновления статистик, то почему бы не обновлять?
...
Рейтинг: 0 / 0
06.05.2020, 11:11
    #39954525
msLex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Daba,

Если вам нужно пересчитать статистику после всех вставок в # таблицу, используйте update statistics
...
Рейтинг: 0 / 0
06.05.2020, 14:18
    #39954595
komrad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
aleks222

Можно заменить #table на @table - в таблицах-переменных для оптимизатора, по-умолчанию, 1-запись.

и для них даже можно индексы создавать
https://www.sqlpassion.at/archive/2013/06/26/non-clustered-indexes-on-table-variables-in-sql-server-2014/
...
Рейтинг: 0 / 0
06.05.2020, 14:29
    #39954606
Daba
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Можно конечно делать update statistics но это вообще не камильфо.
Есть алгоритм как определяется или статистика "просрочена".
Да, на самом деле пересчет происходит только перед запросом с аргументом по индексированному полю.
Да, запрос не "песня" но и не страшный: большая темп табл с несколькими лефт джоинами маленьких темп таблиц, иногда с одной и тоже.

Всё правда. Как это объясняет то что в одном случае план жёстко глючит а в другом, с построением индекса в конце, работает хорошо?
...
Рейтинг: 0 / 0
06.05.2020, 14:39
    #39954615
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Daba
Всё правда. Как это объясняет то что в одном случае план жёстко глючит а в другом, с построением индекса в конце, работает хорошо?
Это же сразу было понятно - потому что во втором случае статистика гарантированно идеальная.

UPD К тому же построение индекса благоприятно влияет на скорость вставки.
Мне никогда не приходило в голову делать индекс на пустой временной таблице, как то это странно, неестественно.
...
Рейтинг: 0 / 0
06.05.2020, 15:57
    #39954662
Владислав Колосов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Не припоминаю точно, но разве для временных таблиц статистика пересчитывается при вставке? ИМО это лишние накладные расходы. Здравый смысл подсказывает, что порядок действий должен быть таким - заполнил, проиндексировал, запросил.
...
Рейтинг: 0 / 0
06.05.2020, 17:02
    #39954699
msLex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Владислав Колосов
что порядок действий должен быть таким - заполнил, проиндексировал, запросил.


Если индекс уникальный, то его наличие до вставки гарантирует отсутствие дублей.
...
Рейтинг: 0 / 0
06.05.2020, 17:48
    #39954730
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
msLex
Владислав Колосов
что порядок действий должен быть таким - заполнил, проиндексировал, запросил.


Если индекс уникальный, то его наличие до вставки гарантирует отсутствие дублей.
Если уникальный индекс сделать после вставки, то тоже будет ошибка.
Т.е. это вопрос: "где получить ошибку, во время вставки, или во время создания индекса"; по моему, принципиальной разницы нет.
...
Рейтинг: 0 / 0
06.05.2020, 19:33
    #39954792
Daba
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
alexeyvg,

Создание индекса "инлайн" вовремя создания таблички, одним запросом, потенциально снижает нагрузку на метадату в tempdb.
Ещё раз, всё что вы говорите правильно, но это всё workarounds.
По мне так движок запросов просто глючит.
...
Рейтинг: 0 / 0
07.05.2020, 11:49
    #39954925
Владислав Колосов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Daba,

откуда уверенность, что это не by design? Построение индекса "на лету" никогда не было быстрее построения индекса "по факту", насколько мне известно.
...
Рейтинг: 0 / 0
07.05.2020, 13:24
    #39954968
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Daba
По мне так движок запросов просто глючит.
Ок, ваше мнение понятно, но все остальные, отметившиеся в этом топике, с вами не согласны, и считают, что так и было задумано.
Так же написано в документации на продукт, откуда я приводил цитаты.
...
Рейтинг: 0 / 0
08.05.2020, 14:31
    #39955317
Критик
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
статистики на временных табличках
Daba
Создание индекса "инлайн" вовремя создания таблички, одним запросом, потенциально снижает нагрузку на метадату в tempdb


Что-что? На сколько, по вашему мнению, снижает?
На 0.00001%?
...
Рейтинг: 0 / 0
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / статистики на временных табличках / 21 сообщений из 21, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]