Скопировать индекс на постоянно увеличивающийся столбец datetime на таблицу протоколирования?

Я не администратор базы данных ( "Хорошо!", вы сразу подумаете.)

У меня есть таблица данных регистрации данных с этими характеристиками и шаблонами использования:

Столбец datetime для хранения временных меток журнала, значение которых постоянно увеличивается и в основном (но только в основном) уникально
Частые вставки (скажем, дюжина минут), только в конце диапазона временных меток (регистрируются новые данные)
Нечасто удаляет, навалом, с начала диапазона временных меток (старые данные очищаются)
Нет обновлений вообще
Частый выбор выбирается с использованием столбца временной метки в качестве основного критерия наряду со вторичными критериями для других столбцов.
Нечасто выбирает использование других столбцов в качестве критериев (и не включает столбец временной метки).
Хорошее количество данных, но нигде не достаточно, что я очень беспокоюсь о пространстве памяти

Кроме того, в настоящее время имеется ежедневное окно обслуживания, в течение которого я мог бы оптимизировать таблицу.

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

Я знаю, что кластеризованные индексы определяют хранение фактических данных таблицы (данные хранятся в листовых узлах самого индекса) и что некластеризованные индексы являются отдельными указателями на данные. Таким образом, в условиях запроса кластеризованный индекс будет быстрее, чем некластеризованный индекс - как только мы найдем значение индекса, данные прямо там. Существуют затраты на вставку и удаление (и, конечно, обновление, изменяющее значение столбчатого индекса столбца, было бы особенно дорогостоящим).

Но я читаю в этом ответе, который удаляет пробелы в разрешении, которые не очищаются до/если индекс не будет восстановлен.

Все это говорит мне, что я должен:

Поместите кластеризованный индекс в столбец временной отметки со 100% -ным заполняющим фактором
Поместите некластеризованные индексы в любой другой столбец, который может использоваться в качестве критерия в запросе, который также не включает кластерный столбец (который может быть любым из них в моем случае)
Запланировать массовые удаления в течение ежедневного периода обслуживания
Запланировать перестройку кластерного индекса сразу после массового удаления
Расслабьтесь и выходите больше.

Неужели я там одинок? Нужно ли мне часто перестраивать индекс таким образом, чтобы избежать большого количества потраченного впустую пространства? Есть ли другие очевидные (для DBA) вещи, которые я должен делать?

Спасибо заранее.

Ответ 1

Я согласен с помещением кластерного индекса в столбец timestamp. Мой запрос будет на fillfactor - 100% дает лучшую производительность чтения за счет производительности записи. вы можете пострадать от разрывов страниц. Выбор нижнего заполняющего фильтра приведет к задержке разделения страниц за счет производительности чтения, поэтому его тонкий балансирующий акт станет лучшим для вашей ситуации.

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

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

Ответ 2

Вопреки тому, что, по мнению многих, наличие хорошего кластерного индекса на столе может фактически ускорить операции типа INSERT - да, быстрее!

Отъезд оригинального сообщения в блоге Дискуссия с кластеризованным индексом продолжается. Кимберли Трипп - конечная индексирующая королева.

Она упоминает (примерно в середине статьи):

Вкладыши быстрее в кластеризованных таблицу (но только в "правильном" кластеризованная таблица), чем по сравнению с куча. Основная проблема здесь в том, что поиск в IAM/PFS для определения расположение вставки в куче медленнее, чем в кластеризованной таблице (где местоположение вставки известно, определяемый кластеризованным ключом). Вставки быстрее вставляются в таблицу где порядок определен (CL) и где этот порядок все возрастает.

Решающим моментом является то, что только с правильным кластеризованным индексом вы сможете воспользоваться преимуществами - когда кластеризованный индекс является уникальным, узким, стабильным и оптимально все возрастающим. Это лучше всего использовать с колонкой INT IDENTITY.

У Кимберли Триппа также есть отличная статья о том, как выбрать наилучший возможный ключ кластеризации для ваших таблиц и какие критерии он должен выполнить - см. ее сообщение под названием Ever - увеличение ключа кластеризации - обсуждение кластерного индекса.......... снова!

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

Ответ 3

Существует два способа "лучшей практики" индексирования таблицы регистрации трафика:

целочисленный столбец идентификатора как основной кластерный ключ
уникальный идентификатор в качестве первичного ключа с DEFAULT NEWSEQUENTIALID()

Оба метода позволяют SQL Server эффективно расширять таблицу, поскольку он знает, что дерево индексов будет расти в определенном направлении.

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

Ответ 4

Очевидный ответ зависит от того, как вы его запросите. Точка индекса заключается в уменьшении количества сравнений при выборе данных. Кластеризованный индекс помогает, когда вы рассматриваете, какие данные вы будете загружать вместе, и фактор блокировки хранилища (вы можете загрузить кучу данных в блоке размером 64 КБ с одним чтением). Если вы включаете идентификатор и дату-время в качестве первичного ключа, но не используете их в своих критериях выбора, они не будут ничего, кроме как помешать вашей работе. Вот почему люди обычно бросают индексы на объемные вставки перед загрузкой данных.