Цитата:
Сообщение от
Kabardian
Почему в стандарте на таблице InventSettlement нет индекса по полю Cancelled? Нашел немало кода, где имеется проверка по полю, а индекс отсутсвует, код детально не изучал, поэтому пока сложно самому ответить на вопрос.
Для ответа на сей вопрос - нужно понять - что нам даст индекс по этому полю.
Теоретически, при сортировке по индексу (в порядке полей, указанных в индексе) - мы можем уменьшить количество записей, внутри которых осуществляется поиск.
Т.е. написав where cancelled = NoYes::No мы отсекаем кучу записей... Но и куча остается. Оставшееся количество все равно велико (нам индекс радикально не помог), а значит оптимизатор будет искать иные индексы для поиска.
Пример. Вы хотите в библиотеке найти книжку автора Пупкина, выпущенную в РФ.
Как Вы будете сначала искать - по фамилии или по стране выпуска? (Предположим, что в библиотеке есть книжки, выпущенные только в СССР и РФ). При этом - книжек, выпущенных в РФ заведомо меньше.
Скорее всего Вы будете искать книжку по фамилии и наплюете на страну издания (т.е. на первое место в индексе поиска поставите не страну, а фамилию).
Также посчитает и оптимизатор.
Также, обращаю внимание - что в идеале - индекс нужен по всем полям, входящим в условие WHERE, а также в сортировку / группировку.
При этом в индексе должны быть на первых местах наиболее селективные поля (т.е. поля, количество значений в которых наиболее уникально в таблице). В случае библиотеки - это фамилия. Поэтому индексы по полям-енумам вообще бессмысленны . Но иногда они нужны, чтобы оптимизатору "подсказать" взять нужный индекс.
Вот поэтому и нет индекса по этому полю. Выборок только по этому полю нет, а включение его в другие индексы возможно, ... но он будет где-нибудь в конце и его роль будет минимальна.
Цитата:
Сообщение от
Kabardian
Стоит ли добавить индекс, если в таблице InventSettlement более чем 40 млн записей?
Честно потратил 10-15 минут на поиск, но вроде никто никогда не задавал таких вопросов.
Знаю, что можно удалить записи с Cancelled=NoYes::Yes, сейчас вопрос в том, имеет ли такая оптимизация право на жизнь и какой будет эффект.
Есть такой момент. Любое добавление / изменение индекса на таблице ведет к ее реиндексации. (DBCC DBREINDEX 'Table'). Если у Вас есть на чем тестировать - попробуйте выполнить запрос после реиндексации таблицы. После этого добавьте это поле в индекс и снова выполните запрос. Вы вряд ли заметите сколько-нибудь значимых изменений. Т.е. по сути - вопрос - сколько на одну запись Cancelled = NoYes::No у Вас соответствующих записей Cancelled = NoYes::Yes. Вот среди них и будет отбор. А это обычно малое количество записей (сколько раз перезакрывали склад за один и тот же период? Умножаем на 2)
Удаление записей конечно же даст эффект. Искать станет проще (среди меньшего количества записей). Закрытие склада ускорится во времени. Также рекомендую еще дефрагментировать табличку, а то "бегать" по разбросанному файлу на диске - тоже скорости не добавляет. А для дефрагментации нужно сделать кластерный индекс.
Я делал кластерный индекс по следующим полям (список полей соответствует порядку полей в индексе):
TransRecId,
TransDate,
Cancelled