Производительность нечисловых индексов

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

Как правило, вы хотите, чтобы ваши индексы были как можно меньше, поэтому nvarchar (4000) (до 8000 байт) будет действительно отстойным, но varchar (3) (до 3 байтов) будет меньше, чем int (4 байта). Также вы хотите (где это возможно) вставить индексную вставку в конец индекса, чтобы индекс не фрагментировался и не вызывал проблем с производительностью.

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

см. основы индексирования сервера Sql для обзора индексов.

Было бы полезнее, если бы вы предоставили более конкретные сведения о самой таблице и о том, как вы хотите ее использовать?

Колин,

nvarchar использует вдвое больше места, чем столбец varchar. Если столбец nvarchar является единственным индексом в таблице, то удар может НЕ быть таким большим, но если у вас есть некластеризованные индексы также в этой таблице, тогда да, у вас будет удар по производительности. Это связано с тем, что кластеризованный индекс включен во все строки для некластеризованных индексов, а ваши некластеризованные индексы будут очень широкими. С другой стороны, столбец int занимает всего 4 байта и имеет большой диапазон для хранения значений от -2 147 483 648 до 2 147 483 647 и имеет тенденцию быть узким. Для 4 байтов столбец nvarchar может хранить не более пространства, используемого varchar (2), поскольку он использует вдвое больше места, чем столбец varchar. Вы видите, сколько места вы тратите впустую?

Почти наверняка да.

Узкий, числовой и строго монотонный ключ является хорошим кластерным ключом. nvarchar не является ни одним из них.

Каждая запись некластеризованного индекса ссылается на кластеризованный индекс, поэтому вы также раздуете индексы NC.

Это до проблем сопоставления/сравнения.

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

Говоря об индексах, вы должны разделить «производительность» на две темы.

При вставке, обновлении и удалении индекс будет замедлять вашу базу данных - в большей степени с кластеризованными индексами, чем с некластеризованными, потому что, возможно, придется перемещать данные в базовом хранилище данных. Здесь я согласен с Джоном, что последовательный int будет работать лучше, чем nvarchar.

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

Таким образом, ответ на ваш вопрос действительно зависит от того, беспокоитесь ли вы о производительности при вставках или чтении.