Дизайн указателя таблицы

Я бы не стал добавлять какие-либо индексы, если у вас нет особых причин для этого, например. проблемы с производительностью.

Для того, чтобы разобраться, какие именно индексы добавлять, нужно знать:

• какие запросы используются к вашей таблице - какие предложения WHERE, какие ORDER BY вы делаете?

• как распределяются ваши данные? Какие столбцы достаточно избирательны (‹ 2% данных), чтобы их можно было индексировать

• какое (негативное) влияние дополнительные индексы оказывают на ваши INSERT и UPDATE в таблице

• любые столбцы внешнего ключа должны быть частью индекса — предпочтительно в качестве первого столбца индекса — чтобы ускорить JOIN с другими таблицами.

И конечно, вы можете проиндексировать столбец DATETIME — почему вы решили, что не можете?? Если у вас есть много запросов, которые будут ограничивать свой набор результатов с помощью диапазона дат, может иметь смысл индексировать столбец DATETIME - возможно, не сам по себе, а в составном индексе вместе с другими элементами вашей таблицы.

Что вы не можете индексировать, так это столбцы, которые содержат более 900 байт данных - что-то вроде VARCHAR(1000) или чего-то подобного.

Подробную и полезную информацию об индексировании см. в блоге Кимберли Трипп, королева индексации.

в общем индекс ускорит JOIN, операцию сортировки и фильтр

ТАК, если столбцы находятся в предложении JOIN, ORDER BY или WHERE, тогда индекс поможет с точки зрения производительности... но всегда есть но... с каждым индексом, который вы добавляете, операции UPDATE, DELETE и INSERT будут быть медленным, потому что индексы должны поддерживаться

так что ответ ... это зависит

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

Шаг первый — понять, как будут использоваться данные в таблице: как они будут вставляться, выбираться, обновляться, удаляться. Не зная своих моделей использования, вы стреляете в темноте. (Обратите также внимание: что бы вы ни придумали сейчас, вы можете ошибаться. Обязательно сравните свои решения с реальными моделями использования, как только вы начнете работать.) Некоторые идеи:

Если пользователи будут часто искать отдельные элементы в таблице, индекс первичного ключа имеет решающее значение.

Если данные будут вставляться с большой частотой и у вас есть несколько индексов, со временем вам придется столкнуться с фрагментацией индекса. Прочтите и поймите кластеризованные и некластеризованные индексы и фрагментацию (ALTER INDEX... REBUILD).

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

Если вам часто нужен набор данных на основе состояния, индексирование этого столбца может быть полезным, особенно если 1% ваших строк являются «активными» по сравнению с 99% «неактивными», и все, что вам нужно, это активные.

И наоборот, если ваш «PriorityId» используется только для получения «метки», указывающей, что такое PriorityId 42 (т. е. присоединение к таблице поиска), вам, вероятно, не нужен индекс для него в вашей основной таблице.

И последняя идея: если все всегда будут извлекать данные только для одной компании за раз, то (а) вы обязательно захотите проиндексировать это, и (б) вы, возможно, захотите рассмотреть возможность секционирования таблицы по этому значению, поскольку оно может действовать как «встроенный фильтр» помимо обычного индексирования. (Возможно, это немного экстремально, и это доступно только в версии Enterprise, но в вашем случае это может стоить того.)