zzzzzzzzzzMindSergey Syrovatchenko,

А что кто то еще дефрагментирует индексы? А зачем?

SQL Server пофигу на все ваши ссд и видимость быстрой работыПруф пожалуйста?

zzzzzzzzzzMindпропущено...
Пруф пожалуйста?
Если индех фрагментировался по какой-либо причине оптимизатор запросов перестанет его использовать и будет вам фуллскан. Фу какой фрагментированный индекс. Я не буду его использовать.

Для начала, на внешнюю фрагментацию оптимизатору пофигу, к тому же ему негде ее взять. Остается внутренняя или заполненность страниц. Если речь про поиск по индексу, то вообще побоку что там с заполненностью страниц. Ну будет индекс на 30% больше и что? Как это на стоимость то повлияет? Количество логических чтений то не поменяется.
Если речь про скан индекса vs скан таблицы, то расскажите мне какая заполненность страниц должна быть у индекса чтобы он стал больше чем таблица? Даже в самом вырожденном случае если таблица очень узкая из 2х колонок, чтобы индекс стал больше таблицы заполненность должна упасть ниже 50% что по факту просто невозможно!

zzzzzzzzzz https://sqlperformance.com/2017/12/sql-indexes/impact-fragmentation-plans
https://www.sqlskills.com/blogs/jonathan/does-index-fragmentation-matter-with-ssds/
https://sqlperformance.com/2017/12/sql-indexes/impact-fragmentation-planshttps://www.sqlservercentral.com/forums/reply/1379912 Самый первый комментарий от весельчака Брента порадовал: "the fragmented query runs FASTER, not slower"

Вторая ссылка, для вырожденного примера с равнораспределенным ключем и сканом таблицы: " The actual runtimes of the two tests were nearly identical, and often flipped back and forth between which one took a few milliseconds longer than the other to complete for this demo. "
Возможно если база используется как data warehouse и в ней много сканов то может иметь смысл дефрагментировать, но не для OLTP нагрузки.

Аргументы Пола по сути противоречат друг другу:
"1. SSDs in no way stop the cause of index fragmentation: page splits from pages needing free space for a random insert or row size increase. A page split generates the same amount of transaction log, resource usage, and potential thread waits regardless of where the data/log files are stored.
2. Index fragmentation includes having many data/index pages with low page density (i.e. lots of empty, free space). Do you really want your expensive SSDs storing lots of empty space? SSDs don’t help here at all."
Чтобы избавиться от #1 (page splits) нужно по сути делать ребилд с fillfactor ниже 100, но сколько? 95, 90, 80? Если сделать слишком высокий то страницы быстро заполнятся и пойдут опять таки page splits, а если низкий, то чем ниже мы делаем fillfactor, тем сильнее получается фрагментация сразу после дорогостоящей операции ребилда! И таким образом получаем таки "low page density" прям по #2. Ну или я не так его понял.

Я не против обслуживания индексов как такового, я просто про то что в большинстве случаев ребилды всего подряд по бездумному правилу 5% - 30% не имеют особого смысла.

zzzzzzzzzzMind>>Я не против обслуживания индексов как такового, я просто про то что в большинстве случаев ребилды всего подряд по бездумному правилу 5% - 30% не имеют особого смысла.
Я с вами уже почти согласен :) Зависит от конкретного случая.

пропущено...

при выборе индекса опимизатор стотрит на статистику и количество страниц индекса которое вырастет при фрагментации (где-то было в ссылках выше). Само абсолютное значение фрагментации в %% не смотритЕще раз. Это имеет значение только при скане индекса, потому что только тогда нужно прочитать все страницы, следовательно оценка расчитывается как [количество страниц в индексе] * [magic number]. Если же у нас поиск, то по барабану, ибо общее количество страниц в индексе никак не учитывается, какая разницы у вас индекс 10Гб или 15Гб если вам нужно прочитать 1 строку? Возможно на маленьких индексах будет на одно нелистовое чтение больше, но это во-первых, ничтожное падение производительности, во-вторых на больших таблицах даже такой разницы не будет.

Короче, если у вас огромное хранилище данных и много сканов, то возможно стоит дефрагментировать, лучше во время загрузки данных в то хранилище :)
Если у вас огромная, но правильно спроектированная OLTP база, и сканов нет, то смысл создавать лишнюю нагрузку без очевидного выигрыша, особенно если это 24/7 и нет больших технических окон? Если же есть сканы, тогда возможно лишняя нагрузка от сканов перевешивает ребилды, но тоже не факт. Как было написано в одной из статей, SSD может сгладить негативный эффект от фрагментированных индексов если дисковая не сильно нагружена.