Лучшее использование индексов во временных таблицах в T-SQL

Question

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

«Таблица должна содержать данные при создании индекса.Если вы создаете временную таблицу и создаете индекс для пустой таблицы, Adaptive Server не создает статистику по столбцам, такую ​​как гистограммы и плотности.Если вы вставите строки данных после создания индекса, оптимизатор будет иметь неполную статистику».

но недавно коллега упомянул, что если я создам временную таблицу и индексы в хранимой процедуре, отличной от той, которая фактически использует временную таблицу, то оптимизатор Adaptive Server воля уметь ими воспользоваться.

В целом, я не большой поклонник процедур-оболочек, которые не приносят особой пользы, поэтому у меня не было времени протестировать это, но я решил задать вопрос, чтобы посмотреть, есть ли у кого-нибудь другие подходы или советы?

Answer 1

Несколько мыслей:

• Если ваша временная таблица настолько велика, что вам приходится ее индексировать, есть ли лучший способ решить проблему?

• Вы можете заставить его использовать индекс (если вы уверены, что индекс является правильным способом доступа к таблице), дав подсказку оптимизатору в форме:

  SELECT * 
  FROM   #table (index idIndex) 
  WHERE  id = @id
  

Если вас интересуют советы по производительности в целом, я подробно ответил на пару других вопросов по этому поводу:

• Любимые приемы настройки производительности
• Как вы оптимизируете таблицы для конкретных запросов?

Answer 2

В чем проблема с добавлением индексов после помещения данных во временную таблицу?

Вам следует помнить одну вещь: видимость индекса для других экземпляров процедуры, которые могут выполняться в то же время.

Мне нравится добавлять руководство к такого рода временным таблицам (и к индексам), чтобы гарантировать отсутствие конфликтов.Другое преимущество этого подхода заключается в том, что вы можете просто превратить временную таблицу в настоящую таблицу.

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

Answer 3

В Sybase, если вы создаете временную таблицу, а затем используете ее в одном процессе, план выбора строится с использованием примерно 100 строк в таблице.(План строится, когда процедура запускается до заполнения таблиц.) Это может привести к сканированию временной таблицы, поскольку она содержит всего «100 строк».Вызов другой процедуры заставляет Sybase построить план выбора с фактическим количеством строк, что позволяет оптимизатору выбрать лучший индекс для использования.Я видел значительные улучшения при использовании этого подхода, но протестируйте его на своей базе данных, поскольку иногда разницы нет.