Нужен совет по выбору кластеризованного индекса для таблицы регистрации

Question

Я использую SQL Server 2005. У меня есть простая таблица журналов, которую мое веб-приложение использует для отслеживания действий пользователей и посещенных URL-адресов. Конструкция стола очень проста

ID (идентификационное значение),

LogDate (datetime),

Активность (nvarchar (200)),

Url (nvarchar (1000))

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

Мне интересно, лучше ли мне изменить его кластерный индекс на столбец LogDate. Столбец LogDate хранит дату / время действия и может иметь дубликаты, но поскольку мы всегда вставляем в таблицу, новые записи должны всегда находиться в конце таблицы, поэтому для SQL Server нет причин для реорганизации. или делить страницы, которые могут повлиять на производительность вставки. Наличие столбца LogDate в качестве кластеризованного индекса также должно повысить производительность поиска.

Пожалуйста, дайте мне знать, если мои рассуждения верны. Спасибо!

Answer 1

Да, ваши рассуждения верны, при условии, что скорость вставок намного меньше, чем степень детализации datetime ( 3,33 мс )

SQL Server 2008 имеет новый тип данных DATETIME2 с более высокой точностью (100 наносекунд).

Если вы оставите разумное количество свободного места (FILLFACTOR между 80-90) и будете регулярно перестраивать индекс (один раз в неделю), все должно быть хорошо.

Answer 2

Прежде чем выбирать кластеризационные индексы, нам нужно установить приоритеты. Что важнее: ускорение редких отборов или минимальное замедление частых вставок? Если ваши вставки важнее, сохраните существующий индекс кластеризации.

Answer 3

Я думаю, что лучше всего использовать «Мастер настройки ядра СУБД». Это позаботится о выборе лучшего варианта для вашего случая. Вам просто нужно запустить его достаточно долго, чтобы охватить разные случаи, чтобы его анализ лучше соответствовал вашему реальному случаю.

Вы можете найти больше на http://msdn.microsoft.com/en-us/library/ms189303%28SQL.90%29.aspx (для SQL Server 2005)