#sql #sql-server
#sql #sql-сервер
Вопрос:
Мне нужно запретить сканирование таблицы в большой таблице, где поиск записи основан на трех полях, одно из которых может быть обновлено. Поисковый запрос выглядит следующим образом:
select blabla from ttg_transaction where uti = ? and txn_type = ? and state = ?
Индекс, который приходит на ум (не уникальный, не кластеризованный), будет содержать три поля выше. Но хотя первые два являются постоянными, «состояние» меняется в течение жизненного цикла записи.
Является ли это хорошей причиной для исключения ‘state’ из индекса?
Ответ №1:
Вещи, которые сделали бы это плохой идеей
- Если у вас медленное хранилище (вращающиеся металлические диски)
- Если ваши типы данных большие (TEXT / NTEXT, VARBINARY, XML, …)
- Высокая частота обновлений.
Или их комбинация.
Предполагая, что у вас быстрое хранилище, я бы не стал сильно беспокоиться. Если у вас все еще медленное хранилище, вы могли бы
- Профилируйте инструкции insert / update
- Создайте индекс
- Профилируйте инструкции insert / update при создании индекса
- Сравните результаты.
Для профилирования вы можете использовать SET STATISTICS IO ON и / или SET STATISTICS TIME ON
Для обработки фрагментации индекса вы могли бы указать коэффициент заполнения, который имеет смысл для вашего случая.
Если состояние является случайным текстовым полем, это также может повлиять на вашу статистику, но вы не указали.
Комментарии:
1. Спасибо за этот ответ. Тип данных ‘state’ — int, поэтому он невелик, частота также не очень высока. Я считаю, что аппаратное обеспечение хорошее, но я должен подтвердить это. Таким образом, дорога открыта для создания индекса со всеми тремя полями и профилирования его, как вы предложили. Коэффициент заполнения также полезно знать для этого индекса и других индексов — это коммерческое приложение, и оно должно быть быстрым, как молния. Еще раз спасибо