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