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

Question

Если я использую столбец nvarchar (n) в качестве кластеризованного индекса в базе данных SQL Server, то получу ли я значительное снижение производительности по сравнению с числовым (int) индексом? Также как сравнивается производительность составных индексов?

Answer 1

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

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

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

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

Возможно, было бы более полезно, если бы вы предоставили более подробную информацию о самой таблице и о том, как вы хотите ее использовать?

Answer 2

Colin

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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