Лучшее использование индексов на временных таблицах в T-SQL
3 ответа
Несколько мыслей:
- , Если Ваша временная таблица является столь большой, что необходимо индексировать ее, затем там лучший способ решить проблему?
-
можно вынудить это использовать индекс (если Вы уверены, что индекс является корректным способом получить доступ к таблице) путем предоставления подсказки оптимизатора, формы:
SELECT * FROM #table (index idIndex) WHERE id = @id
, Если Вы интересуетесь подсказками по производительности в целом, я ответил на несколько других вопросов о том довольно долго здесь:
Какова проблема с добавлением индексов после помещения данных во временную таблицу?
Одной вещью, которую необходимо помнить, является видимость индекса к другим экземплярам процедуры, которая могла бы работать одновременно.
мне нравится добавлять гуид к этим видам временных таблиц (и к индексам), удостоверяться, что никогда нет конфликта. Другое преимущество этого подхода - то, что Вы могли просто сделать временную таблицу реальной таблицей.
кроме того, удостоверьтесь, что необходимо будет запросить данные в этих временных таблицах несколько раз во время выполнения хранимой процедуры, иначе стоимость создания индекса перевесит преимущество для выбора.
В Sybase, если Вы составляете временную таблицу и затем используете ее в одном proc, план относительно выбора создается с помощью оценки 100 строк в таблице. (План создается, когда процедура запускается, прежде чем таблицы заполняются.) Это может привести к временной таблице быть таблицей, просканированной, так как это - только "100 строк". Вызов другого proc заставляет Sybase создавать план относительно выбора с помощью фактического количества строк, это позволяет оптимизатору выбирать лучший индекс для использования. Я видел, что значительный improvedments использует этот подход, но тест на Вашей базе данных как иногда, нет никакого различия.