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

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

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

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

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

Ответ 1

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

Если ваша временная таблица настолько велика, что вам нужно ее индексировать, тогда есть лучший способ решить проблему?
Вы можете заставить его использовать индекс (если вы уверены, что индекс является правильным способом доступа к таблице), указав подсказку оптимизатора:
```
SELECT * 
FROM   #table (index idIndex) 
WHERE  id = @id
```

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

Ответ 2

Какова проблема с добавлением индексов после размещения данных в таблице temp?

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

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

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

Ответ 3

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