Индексы SQL Server - начальная медленная производительность после создания - PullRequest
2 голосов
/ 15 января 2010

Использование SQL Server 2005. Это то, что я заметил при анализе производительности.

У меня есть большая таблица с примерно 100 миллионами строк. Я сравниваю производительность различных индексов в таблице, чтобы увидеть, что наиболее оптимально для моего тестового сценария, который выполняет около 10 000 вставок в эту таблицу, среди прочего в других таблицах. Пока мой тест выполняется, я записываю трассировку SQL Profiler, которую загружаю в таблицу SQL после завершения теста, чтобы можно было проанализировать статистику.

Первый тестовый прогон после воссоздания другого набора индексов в таблице очень заметно медленнее, чем последующие прогоны - обычно примерно в 10-15 раз медленнее для вставок в эту таблицу при первом прогоне после создания индекса.

Каждый раз перед проверкой я очищаю кэш данных и плана выполнения.

То, что я хочу знать, является причиной этой начальной более низкой производительности с недавно созданным набором индексов? Есть ли способ, которым я могу отслеживать, что происходит, чтобы вызвать это при первом запуске?

Ответы [ 2 ]

4 голосов
/ 15 января 2010

Одна из возможностей состоит в том, что по умолчанию коэффициент заполнения с нулем вступает в игру.

Это означает, что в индексе нет места для размещения ваших вставок. Когда вы вставляете, требуется разделение страницы в индексе, что добавляет свободное место для хранения новой информации индекса. Чем больше вставок, тем больше места создается в индексе. Через некоторое время скорость разделения снизится, потому что ваши вставки попадают на страницы, которые не заполнены полностью, поэтому разделение не требуется. Вкладыш, требующий разбиения страницы, стоит дороже, чем тот, который этого не делает.

Вы можете установить коэффициент заполнения при создании индекса. Это классический компромисс между используемым пространством и выполнением различных операций.

Я собираюсь включить ссылку на некоторые документы Sybase ASE , потому что они хорошо написаны и в основном применимы и к SQL Server.

1 голос
/ 15 января 2010

Просто чтобы уточнить:

1) Вы строите индекс для таблицы с уже существующими 100 м строк.

2) Вы вставляете 10k строк в таблицу

3) Вы вставляете еще 10 тысяч строк в таблицу

Шаг 3 в 10 раз быстрее, чем шаг 2?

Что это за индекс новый, не кластеризованный, верно? Потому что вставки в кластеризованном индексе приведут к совершенно другому поведению. Кроме того, есть ли существенная разница в профиле двух вставок, потому что в зависимости от кластеризованного индекса они будут вести себя по-разному. Как правило, он не должен иметь кластеризованного индекса или кластеризоваться по возрастающему ключу.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...