Если я использую столбец nvarchar (n) в качестве кластерного индекса в базе данных SQL Server, получаю ли я значительное повышение производительности по сравнению с числовым индексом (int)? Также как сравнивать производительность составных индексов?Производительность нечисловых индексов
Sql не заботится о том, является ли ваш индекс числовым или нет, но есть некоторые вещи, которые необходимо учитывать в зависимости от того, что находится в столбце и как вы используете таблицу.
Как правило, вы хотите, чтобы ваши индексы были как можно меньше, поэтому nvarchar (4000) (до 8000 байт) действительно сосут, но varchar (3) (до 3 байтов) будет меньше, чем int (4 байта). Кроме того, вы хотите (если возможно) включить вставьте индексную вставку в конец индекса, это приведет к фрагментации индекса и вызовет проблемы с производительностью.
Составные индексы могут значительно повысить производительность, если запросы, которые вы используете против таблицы, содержат только столбцы в индексе. Это означает, что фактическая таблица никогда не затрагивается, так как индекс удовлетворяет запросу.
см. Sql server index basics для обзора по индексам.
Возможно, было бы более полезно, если бы вы рассказали более подробно о самой таблице и о том, как ее использовать?
Почти наверняка да.
Узкий, числовой и строго монотонный делает хороший сгруппированный ключ. nvarchar - ничто из этого.
Каждая запись некластеризованного индекса относится к кластерному индексу, чтобы вы также раздували индексы NC.
Это касается вопросов сопоставления/сравнения.
Я думаю, что это также зависит от размера вашего стола. Для небольших таблиц я сомневаюсь, что вы заметите разницу, но для более крупных, скажем, 1 миллион строк и более, вы можете заметить небольшое замедление с nvarchar. Я бы сказал, что это также зависит от того, что поле на самом деле contains..i.e., Они электронные письма и т.д.
Colin,
NVARCHAR использует двойное пространство столбца VARCHAR. Если столбец nvarchar является единственным индексом в таблице, то это может быть не так много, но если у вас есть некластеризованные индексы на этой таблице, то да, у вас будет удар производительности. Это связано с тем, что кластерный индекс включен во все строки для некластеризованных индексов, а ваши некластеризованные индексы будут очень широкими. С другой стороны, столбец int занимает всего 4 байта и имеет большой диапазон для хранения значений от -2147,483,648 до 2,147,483,647 и имеет тенденцию быть узкими. Для 4 байтов столбец nvarchar может хранить только самое пространство, используемое varchar (2), поскольку оно использует двойное пространство столбца varchar. Вы видите, сколько пространства вы тратите?
Говоря об индексах, вы должны разделить «производительность» на две темы.
При вставке, обновлении и удалении индекс замедляет работу вашего db - тем более с кластеризованными индексами, чем с некластеризованным, поскольку, возможно, придется перемещать данные в базовом хранилище данных. Здесь я согласен с Джоном в том, что последовательный int будет работать лучше, чем nvarchar.
Но если вам нужно запросить в поле nvarchar в любом случае, кластеризованный индекс в этом поле сделает больше, чтобы ускорить чтение.
Таким образом, ответ на ваш вопрос действительно зависит от того, беспокоитесь ли вы о производительности на вставках или чтениях.
Черт, я хотел добавить эту ссылку. +1 – gbn
Максимальное числовое число, установленное для NVARCHAR, равно 4000. Однако есть «NVARCHAR (MAX)», но числовая длина разрешена до 4000 и ниже не более 4000. –
хе-хе, да, хорошая точка. –