Сравнение Sql Server int и nvarchar по производительности?

Question

Для вас гуру дизайна / производительности баз данных.

Я проектирую таблицу, у меня есть выбор: использовать int или nvarchar (128) для столбца, предположим, что пространство не является проблемой.У меня вопрос, который даст производительность

при поиске с использованием столбца int

where ID = 12324

или при поиске с использованием столбца nvarchar (ключ - это полное значение, поэтомуЯ не использую оператор LIKE)

where Key = 'my str'

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

Answer 1

INT будет быстрее - вот почему:

• SQL Server организует свои данные и индексирует по страницам 8K
• , если у вас есть страница индекса с ключом INT, выполучите примерно 2 000 записей INT
• , если у вас есть NVARCHAR (128) и вы используете в среднем 20 символов, то есть 40 байтов на запись, или примерно 200 записей на странице

Такдля того же количества записей индекса случай NVARCHAR (128) будет использовать в десять раз больше страниц индекса.

При загрузке и поиске на этих страницах индекса будет значительно больше операций ввода-вывода.

Короче говоря, если можете, всегда используйте INT.

Answer 2

Пробел всегда проблема в базах данных.Более широкие ключи означают меньше записей на страницу, больше страниц, отсканированных для агрегирования и суммирования значений, означает больше ввода-вывода, меньше производительность.Для кластеризованных индексов эта проблема умножается на каждый некластеризованный индекс, поскольку они должны воспроизводить ключ поиска (кластеризованный ключ) в своих листьях.Таким образом, ключ типа nvarchar(128) будет почти всегда хуже, чем INT.

С другой стороны, не используйте клавишу INT, если это не подходит.Всегда используйте соответствующий ключ , учитывая ваши запросы .Если вы всегда будете выполнять запрос по значению столбца nvarchar (128), тогда возможно хороший кандидат на кластеризованный ключ.Если вы собираетесь агрегировать по ключу nvarchar (128), то вероятно является хорошим кандидатом для кластеризованного ключа.

Answer 3

Основной проблемой производительности при этом является размер поля - int равен 4 байта, тогда как nvarchar(128) будет 254 байта.

Все это должно управляться сервером SQL, поэтому управление int будет намного быстрее, чем nvarchar(128).

Answer 4

Я бы использовал int для производительности (если это будет иметь особенно объединения) и поместил уникальный индекс в потенциальный естественный ключ для целостности данных.