Каковы основные различия в производительности между типами данных SQL Server varchar и nvarchar?

Question

Я работаю над базой данных для небольшого веб-приложения в моей школе, используя SQL Server 2005.
Я вижу пару школ мысли по вопросу varchar против nvarchar:

1. Используйте varchar, если вы не имеете дело с большим количеством интернационализированных данных, затем используйте nvarchar.
2. Просто используйте nvarchar для всего.

Я начинаю видеть достоинства представления 2. Я знаю, что nvarchar занимает вдвое больше места, но это не обязательно огромная сделка, так как она собирается хранить данные только для нескольких сотен студентов. Мне кажется, что было бы проще не беспокоиться об этом и просто позволить всему использовать nvarchar. Или мне чего-то не хватает?

Answer 1

Я часто занимаюсь этим вопросом на работе:

• FTP-фиды инвентаря и цены - описания предметов и другой текст были в nvarchar, когда varchar работал нормально. Преобразование их в varchar уменьшило размер файла почти вдвое и действительно помогло с загрузкой.

• Вышеописанный сценарий работал нормально, пока кто-то не вставил специальный символ в описание предмета (возможно, товарный знак, не помню)

Я до сих пор не использую nvarchar каждый раз над varchar. Если есть какие-либо сомнения или потенциал для специальных символов, я использую nvarchar. Я нахожу, что я использую varchar в основном, когда я на 100% контролирую то, что заполняет поле.

Answer 2

Почему во всей этой дискуссии не упоминалось о UTF-8? Возможность хранить полный диапазон символов Юникода не означает, что нужно всегда выделять два байта на символ (или «кодовую точку», чтобы использовать термин UNICODE). Все ASCII - это UTF-8. Проверяет ли SQL Server для полей VARCHAR (), что текст является строгим ASCII (то есть бит нулевого верхнего байта)? Я надеюсь, что нет.

Если вы хотите хранить Unicode и хотите совместимости со старыми ASCII-приложениями, я бы подумал, что использование VARCHAR () и UTF-8 было бы волшебной пулей: он использует больше места только тогда, когда нужно.

Для тех из вас, кто не знаком с UTF-8, могу я порекомендовать учебник для начинающих .

Answer 3

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

Answer 4

Если вы используете NVARCHAR только потому, что этого требует системная хранимая процедура, наиболее частым случаем которого является необъяснимое sp_executesql, а ваш динамический SQL очень длинный, вам будет лучше с точки зрения производительности выполнять все строковые манипуляции конкатенация, замена и т. д.) в VARCHAR, затем преобразование конечного результата в NVARCHAR и подача его в параметр proc. Так что нет, не всегда используйте NVARCHAR!