Хотя уже немного поздно, я собираюсь дать ответ с надеждой, что он поможет или, по крайней мере, отвергнет некоторые дополнительные идеи / комментарии по этому вопросу, потому что я думаю, что это хороший вопрос.
Во-первых, и я не знаю, делаете ли вы это или нет, но, пожалуйста, не думайте, что высокие уровни фрагментации в индексе всегда будут приводить к снижению производительности. Устаревшая статистика (например, sys.dm_db_stats_properties ) и большое количество пустого пространства на странице (т. Е. Столбец avg_page_space_used_in_percent в sys.dm_db_index_physical_stats dmv ) имеют большее отношение к проблемам производительности, чем только фрагментация. Да, сильно фрагментированные индексы будут генерировать больше упреждений при чтении, и вы, как правило, видите устаревшую статистику и более высокие уровни пробелов на странице в сочетании с фрагментацией, но фрагментация напрямую не связана с оптимизацией плана запросов или с тем, сколько памяти загружает индекс с диска будет на самом деле потреблять. На планы запросов влияет статистика, и ваш объем памяти увеличивается с появлением большего количества пустого пространства . Например, индекс, который фрагментирован на 99%, но имеет среднее значение менее 5%. Пробелы и актуальная статистика, скорее всего, не вызовут у вас резких проблем с производительностью по сравнению с плохим планом выполнения из-за устаревшей статистики или постоянной подкачки индекса, который слишком велик для того, чтобы полностью поместиться в памяти, потому что существует значительный объем пустого пространства присутствует на странице.
Если фрагментация действительно является проблемой , вы можете уменьшить ее, ОНЛАЙН, выполнив ALTER INDEX ... REORGANIZEзаявление, определенное Дэном Гусманом в комментариях. Это не создаст такой упорядоченный индекс, как REBUILDоперация, но уменьшит вашу фрагментацию. Ключевым моментом здесь является определение окон более низкого использования в вашей базе данных и запускать его тогда. Это может быть 15 минут или несколько часов, очевидно, чем дольше, тем лучше, но ключевой момент здесь заключается в том, что эта операция не выполняет откат и сохраняет достигнутый прогресс, даже если вы убьете его в середине выполнения.
Если в идеальном мире, где ваша фрагментация была устранена, имеет ли смысл использовать разбиение этой таблицы? База данных SQL Azure допускает разбиение таблиц, и у Microsoft есть отличная статья, в которой изложены некоторые стратегии разделения для базы данных SQL Azure . Если ваши данные не являются летучими, их разбиение может помочь сократить потребности в обслуживании, а в сочетании со сжатием таблиц вы даже сможете уменьшить общий объем памяти. Более ранний ответ Альберто Мурильо намекает на использование горизонтального разбиения основанный на области данных, и этот подход может помочь создать некоторые окна обслуживания для вас, так как ваши данные будут более региональными, а не глобальными.
Переход к секционированной таблице не будет легко с отсутствием в настоящее время окна обслуживания, но вы можете быть в состоянии использовать подход , изложенный Мария Zakourdaev , которая использует секционированные представления поверх текущей таблицы и новая секционированная таблица , чтобы начать секционирование будущие данные. Со временем (и, надеюсь, ваши старые данные будут удалены), вы можете в конечном итоге полностью перейти к разделенной таблице. Опять же, я не знаю ваших данных или приложения, но, возможно, вы можете использовать этот подход.
REORGANIZEуменьшит фрагментацию конечных страниц и уменьшит компактность, какREBUILD, впрочем, и менее эффективно. Вы уверены, что большой размер происходит из-за фрагментации? Что такое коэффициент заполнения?