Кластерный индекс?

Question

У меня есть журнал с (сокращенными, например) следующими столбцами:

user | time | uniqueid | msg

И есть Первичный ключ на

user,time,uniqueid

и Кластерный индекс на

user

Теперь с этой таблицей можно сделать только три вещи:

• вставить запись
• удалить все записи старше x
• выбрать записидля пользователя (максимум 1 Кб за раз)

Выборы происходят редко, вставки происходят постоянно, а удаление происходит один раз за ночь.

Если я правильно понимаю,Кластерный индекс сделает выбор очень быстрым.Из-за объема данных я заметил, что удаление займет очень много времени, и я предполагаю, что это еще хуже из-за кластеризованного индекса.Это правильно?Кроме того, это может также сделать медленные вставки немного медленнее (но числа могут быть небольшими за раз, поэтому это не так легко заметить)

Моя идея будет такой:

• если для кластерного индекса задано время
• , поскольку первичный ключ никогда не используется (ничего не относится к этой таблице или чему-либо еще), имеет ли смысл просто отбросить его и создать другой индекс для пользователя для выбора?

Каков наилучший способ оптимизировать это?

Answer 1

Обычно я бы использовал искусственный первичный ключ, но для таблицы журнала это, по-видимому, не имеет особого смысла, если вы не пропустили требование, касающееся отдельных записей журнала.В этом случае для меня более логично поддерживать ваш первичный ключ, используя некластеризованный индекс со столбцами в указанном вами порядке.Измените кластерный индекс так, чтобы он был вовремя, а не для пользователя.Пользовательские выборки могут использовать индекс, определенный вашим первичным ключом, и, хотя некоторые из них замедляются, все равно должны быть достаточно быстрыми, поскольку они могут использовать сканирование индекса вместо сканирования таблицы.Так как пользователь является первым столбцом, это должно быть довольно быстро, даже если строки больше не являются смежными.Своевременное создание кластеризованного индекса значительно ускорит удаление и, вероятно, уменьшит фрагментацию.Поскольку вы все еще поддерживаете только два индекса, это не должно влиять на производительность вставки.Фактически это может улучшиться, поскольку структура таблицы будет более точно отражать способ вставки данных.

Answer 2

Если UniqueId действительно уникален, как следует из его названия - , то будет идеальным кандидатом в качестве первичного ключа, на мой взгляд!

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

Похоже, у вас есть две основные операции:

• выберите с помощью user
• удалить на основе time

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

Answer 3

Мои предложения:

• Сохранять кластерный индекс для пользователя;это даст хорошие результаты выбора.Добавление времени к вашему кластерному индексу, вероятно, также улучшит производительность выбора, поскольку вы, вероятно, выбираете самые последние записи (время), верно?
• Ваше удаление выполняется медленно, поскольку вы не индексируете время;создайте новый индекс вовремя.
• Вставка может быть немного медленной, но если это происходит не слишком часто, я бы не слишком беспокоился об этом.

Во время пикового использования, сколько вкладок вы видите в час?Выбор?Кроме того, что такое uniqueid?Это GUID?