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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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