Имеет ли значение размер, используемый с NVARCHAR?

Question

Каждый раз, когда я создаю таблицу, я задаюсь вопросом, есть ли разница в производительности, скажу ли я nvarchar (100) или nvarchar (1000), предполагая, что фактический размер строки будет меньше 100.Так есть ли?

Answer 1

Согласно документации :

nvarchar [(n | max)]

Строковые данные Unicode переменной длины.n определяет длину строки и может принимать значение от 1 до 4000.max указывает, что максимальный размер хранилища составляет 2 ^ 31-1 байт (2 ГБ). Размер хранилища в байтах в два раза превышает действительную длину введенных данных + 2 байта.

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

В документации не сказано, почему это так, но параметр длины полезен, поскольку он обеспечивает применение простых ограничений (например, чтобы кто-то не мог ввести 2 ГБ текста в качестве своего «имени»).

Answer 2

Причина, по которой вам не следует использовать nvarchar (1000), когда вам нужен nvarchar (10), заключается в том, чтобы предотвратить попадание неверных данных в вашу базу данных. Если вам не нравится, когда телефонные номера говорят о таких вещах, как «позвоните толстому секретарю, а не милому, если вы хотите получить реальный ответ». какие поля достаточно велики, чтобы их можно было использовать для хранения заметок, в результате чего данные в поле со временем становятся бесполезными.

А что касается nvarchar (Max), то это вообще плохая идея, если вы не предполагаете иметь более 4000 символов. Посмотрите индексирование и varchar (max), чтобы понять, почему.

Answer 3

Что касается размера в зависимости от производительности, помните, что сервер SQL будет хранить начальное значение данных для nvarchar / varchar и все значение для nchar / char в единицах пространства.Например: nvarchar(1000) с сохраненными данными test data первоначально будет занимать 9 * 2 байта или 18 байтов.В то время как nchar(1000) будет принимать 1000 * 2 байта (2000 байт), не смотря ни на что.

Затем он продолжит свой веселый путь, добавляя следующий набор данных на странице (то есть 8 КБ) до тех пор, пока страница не появится на странице.соответствует (или близко) к коэффициенту заполнения, установленному для таблицы.Затем начинается новая страница.Теперь предположим, что пользователь должен обновить эти данные и ввести что-то с некоторым содержанием в предыдущем поле, скажем, что-то длиной 800 символов.Теперь это значение необходимо обновить и будет значительно увеличиваться, но теперь страница заполнена, и когда данные для этого поля должны увеличиться, страница должна разделиться и освободить место для данных (если коэффициент заполнения не достаточно низок, чтобы учестьрост).

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

Как часто бывает, ответ: «зависит».

Answer 4

Да, это важно с точки зрения производительности.

Оптимизатор запросов просматривает эти метаданные для планирования запроса. Он оценивает размер строки на основе предоставленной длины, что может привести к снижению производительности. Например, если вам нужно отсортировать столбец с именем varchar (10), он может запланировать выполнение операции сортировки в ОЗУ, но тот же запрос для varchar (1000) может быть запланирован для выполнения на вторичном хранилище.

Я пытаюсь использовать знания предметной области и оценить необходимый размер. Кроме того, вам может понадобиться место для будущего обслуживания. Например, если вы считаете, что ваши данные могут содержать не более 50 символов, используйте varchar (70) вместо 50, чтобы он мог обрабатывать непредсказуемые будущие изменения в использовании приложения.

Я узнал об этом из этого поста в блоге (я НЕ автор): http://aboutsqlserver.com/2010/08/18/what-is-the-optimal-size-for-variable-width-columns/

---

ПРИМЕЧАНИЕ: не выбирайте меньшую длину вслепую. Изменение размера поля может стать большой головной болью при обслуживании. Я помню, когда я выбирал небольшую длину для поля LastName, и некоторые пользователи не могли зарегистрироваться в системе из-за этого. Нам пришлось обновить критическую базу данных, которая используется (для увеличения длины поля требуется время), скомпилировать программу и заново развернуть ее. Если бы я выбрал правильный размер поля, я мог бы избежать всех этих головных болей.

Вы также можете прочитать о различиях между nvarchar (max) и nvarchar (n), так как n> 4000 для 4000 делает поле в основном похожим на nvarchar (max). ( Есть ли недостатки при использовании nvarchar (MAX)? )

Answer 5

По крайней мере, в базе данных сервера sql запрещено создавать уникальное ограничение для столбца с его типом nvarchar (max).Для успешного добавления этого ограничения следует ограничиться nvarchar (450).

Answer 6

Поскольку nvarchar является типом данных переменной длины, он будет хранить только данные, которые вы ему назначаете (2 байта на символ), плюс 2 байта для информации о длине и в основном используется для двухбайтовых языков, таких как китайский.

Лично я использую varchar (n), когда знаю об определенном ограничении (например, ограничение строки запроса URL-адреса, ограничение размера пути к файлу или мой собственный предел).Я использую varchar (max), когда максимальная длина не определена и может превышать 8000 символов.И я почти никогда не использую nvarchar, потому что наше приложение никогда не выйдет на международный уровень.