Комментарии 16
Скажите, а вы ЛИЧНО встречались с ситуацией, когда применение REBUILD значимо и достоверно увеличивала производительность сервера? за исключением случая BULK INSERT или соотв. UPDATE на уровне ~10% объёма записей, разве что...
Не могу похвастаться гипер-объёмами... а потому лично от такого обслуживания наблюдал всего лишь эффект, сравнимый с плацебо.
К примеру у меня такое бывало, на самом деле. Деталей не помню. Но помню, что обновление статистик и перестройка индексов сильно ускоряли запросы. Было это, правда, давно уже, с тех пор многое могло поменяться в движках БД.
с тех пор наверное и ситемы хранения информации поменялись с HDD на SSD.
Поддержу Akina, в обновлении статистики верю, в перестройку индексов - нет.
Тут, мне кажется, плюс не в увеличении производительности, а в том чтобы оная не уменьшалась, потому как с фрагментированными данными производительность точно упадет. "Нужно бежать со всех ног, чтобы только оставаться на месте..."
Есть примеры с замерами?
При чтении с диска производительность точно (на самом деле уже не точно) упадёт, и не факт, что снижение производительности при чтении фрагментированного индекса будет заметно меньше, чем при чтении нефрагментированного. А если данные уже в памяти - будет ли разница?
Разница может быть заметна в случае, если на страницах много свободного места, но это обычно не то, что понимают под фрагментацией. В статье тоже акцент на порядке страниц, а не их содержимом.
Нет, только логические умозаключения (и немного буквоедства) ). Производительность нельзя увеличить, дефрагментировав индексы. Максимум ее можно вернуть к начальным значениям, близким к тем, когда база была только создана и содержала мало данных. Можно подтюнинговать настройки, хотя это больше к серверу БД относится.
А чтобы действительно увеличить производительность, нужно добавить памяти/процессоров или заменить диски на более производительные.
После этой статьи стоит почитать про:
fill factor
rebuild with online
partitioned tables
#вкачестверемарки #cоветысдивана
На самом деле, до любых операций с индексами, хорошо бы оценить ситуацию по каждой таблице. И специально для этого придумали универсальные скрипты, рекомендую: https://ola.hallengren.com/
А если посмотреть глубже, то на больших таблицах в highload на дефрагментацию пофигу. Нормальная работа ssd нивелирует потери чтения фрагментов.
Таблицу на пару сотен млн строк дефрагментировать можно часами.
Мы для таких таблиц используем только обновление статистики, а дефраг или ребилд, только изредка, когда есть техокно.
В какой ситуации фрагментация индекса повлияет на этот запрос? Насколько сильно?
SELECT * FROM MyTable WHERE ID = 12345
В случае, когда ID не уникальны? В случае, когда было много удалений и в индексе "образовался" "лишний" уровень?
Вообще, было бы здорово, если бы в примерах были не просто примеры запросов, а рельная статистика выполнения - с фрагментированным индексом и с дефрагментированным.
Есть две хорошие статьи про фрагментацию индексов: Stop Worrying About SQL Server Fragmentation и When Does Index Fragmentation Matter?. И в целом весь блог полезен )
Не использую MS SQL в работе, но рад был прочитать в своё время о работе специалиста, который создал скрипт для обслуживания баз данных 24/7. Рекомендую!
Дефрагментация таблиц в высоко нагруженных базах данных (MSSQL)
https://habr.com/ru/articles/724702/
MSSQL: ребилд индексов в высоко нагруженных системах, Standard Edition
https://habr.com/ru/articles/748348/
MSSQL: Rebuild vs Reorganize в высоконагруженных системах
Как фрагментация индексов в SQL Server «подкладывает свинью» производительности, и что с этим делать