Рекомендация по индексу SQL Db

Question

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

[Редактировать: мы используем MS SQL Server 2008 R2]

У меня есть база данных SQL, содержащая данные измерений с метками времени.Много данных вставляется постоянно, но после вставки их практически никогда не требуется обновлять.Эти временные метки, однако, не уникальны, поскольку несколько устройств (около 50 из них) измеряют данные одновременно.

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

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

Поскольку мои данные имеют временную метку, а данные вставляются почти последовательно (увеличение временных меток), мне интересноесть более умный способ создания первичного ключа с уникальным кластеризованным индексом для этой таблицы.Столбец метки времени в основном представляет собой число bigint (тики .NET DateTime).

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

Answer 1

Может быть, посмотрите на этот ответ , HiLo выглядит интересно.

Кроме того, возможно, ваша фрагментация не является результатом несоответствия между порядком значений индекса и порядком их добавления, а естественным эффектом роста файла (как объяснено здесь )?

Answer 2

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

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