Могу я спросить, есть ли способ узнать подходящее время для обновления статистики таблицы / индекса?
В последнее время производительность ухудшается с одной из основных таблиц витрин данных в нашем BI-DWH, SQL Server 2012. Каждые выходные обо всех индексах заботятся о реорганизации / перестройке в соответствии с их процентом фрагментации, и теперь они составляют менее 5%, как avg_fragmentation_in_percent.
Таким образом, мы обнаруживаем, что это вызвано устаревшей статистикой таблиц / индексов или фрагментацией таблиц или около того.
Как правило, мы устанавливаем автоматическую статистику, и эта статистика таблиц / индексов была обновлена в июле 2018 года, возможно, еще не время обновлять в соответствии с их оптимизатором, поскольку эта таблица огромна, общая запись составляет около 0,7 миллиарда, ежедневный прирост составляет около 0,5 миллиона записей.
Вот статистика PK и фактическое количество записей в этой таблице.
-- statistics
dbcc show_statistics("DM1","PK_DM1")
Name Updated Rows Rows Sampled Steps Density AveragekeylengthString Index Filter Expression Unfiltered Rows
------------------------------------------------------------------------------------------------------------------------------------------------------
PK_DM1 07 6 2018 2:54PM 661696443 1137887 101 0 28 NO NULL 661696443
-- actual row count
select count(*) row_cnt from DM1;
row_cnt
-------------
706723646
-- Current Index Fragmmentations
SELECT a.index_id, name, avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats (DB_ID(N'DM1'),
OBJECT_ID(N'dbo.DM1'), NULL, NULL, NULL) AS a
JOIN sys.indexes AS b
ON a.object_id = b.object_id AND a.index_id = b.index_id;
GO
index_id name avg_fragmentation_in_percent
--------------------------------------------------
1 PK_DM1 1.32592173128252
7 IDX_DM1_01 1.06209021193359
9 IDX_DM1_02 0.450888386865285
10 IDX_DM1_03 4.78448190118396
Таким образом, разница между количеством строк статистики и фактическим количеством записей составляет менее 10%, но более 45 миллионов. Мне интересно, стоит ли в этом случае обновлять статистику таблицы / индекса вручную.
Если есть какая-либо другая информация, которую вы определили в подходящее время для обновления статистики, мы будем очень признательны за любой совет.
Спасибо.
-- Результат
Благодаря совету @scsimon я подробно проверил всю статистику индекса, и в основном индексе отсутствовал RANGE_HI_KEY - этот индекс основан на дате регистрации, и после последнего обновления статистики в июле 2018 года не было диапазона. (Заявление было сделано пользователем, когда он искал записи за сентябрь 2018 г.)
Поэтому я решил обновить статистику таблиц / индексов и подтвердил, что тот же запрос был улучшен с 1 часа 45 минут до 3,5 минут.
Дилпи оценил все советы по моему вопросу.
С уважением.
Я бы сказал, что вам нужна веская причина, чтобы отклониться от рекомендуемых рекомендаций: docs.microsoft.com/en-us/sql/relational-databases/indexes/…
Спасибо за ссылку, @ user1443098. Но я думаю, что фрагментация индекса невысока. Если возникнет недоразумение, дайте мне знать.
IIUC, вы спросили, когда обновлять статистику и индексы. Я бы установил автоматическую статистику и реорганизовал / перестроил индексы в соответствии с рекомендациями, за исключением особых обстоятельств. И я видел несколько таких!
@ user1443098 еще раз спасибо :)





Что ж, у вас есть автоматическое обновление статистики, так что это хорошо. Кроме того, каждый раз, когда индекс перестраивается, статистика пересчитывается. SQL Server 2008R2 и более поздних версий, до 2016 года, ведет себя так же, как TF 2371, что означает, что большая таблица занимает меньше строк и требует перехода на автоматическое вычисление. Подробнее об этом читайте здесь.
Также вы показываете статистику по одному индексу, а не по всей таблице. Этот индекс можно отфильтровать. И помните, что Общее количество строк, выбранных для статистических расчетов. Если количество строк выборки <строк, отображаемая гистограмма и результаты плотности являются оценками на основе выбранных строк.Вы можете прочитать об этом здесь
Вернемся к основной проблеме производительности ... вы сосредотачиваетесь на статистике и индексах, что не является ужасной идеей, но это не обязательно первопричина. Вам необходимо определить, что запрос какие выполняется медленно. Затем получить помощь с этим медленным запросом, но следуя инструкциям в этом блоге и других. Важнее всего задать вопрос об этом запросе с планом выполнения. Проблема может быть в индексах, или это может быть:
Большое спасибо за ваш добрый и ясный совет, @scsimon. Как вы любезно упомянули, проблема с производительностью может быть вызвана многими факторами, не только простой статистикой и индексом - на самом деле конкуренция за память, медленные диски и нехватка свободного места на диске могут быть другими причинами в нашей системе. Я проверю наши таблицы витрины данных более подробно в соответствии с «Внутри гистограммы статистики и вектора плотности», вы любезно представили ее, это так интересно :) Большое вам спасибо.
после ссылки на ваши документы и в каком-то индексе отсутствует «RANGE_HI_KEY», ключ которого основан на дате регистрации. Поэтому я решил обновить статистику и подтвердил, что производительность значительно улучшилась. Большое спасибо за всю вашу полезную информацию :) (Я обновлю результат в своей ветке только для вашей информации)
Совсем не беспокойся @Sachiko
Как узнать, что проблемы с производительностью вызваны проблемами со статистикой?