Производительность SQL: есть ли снижение производительности при использовании NVarchar (MAX) вместо NVarChar (200)

Question

Мне интересно, есть ли какой-либо недостаток при определении столбца типа nvarchar (max) вместо того, чтобы придавать ему (меньший) максимальный размер.

Я где-то читал, что если значение столбца имеет больше 4? КБ оставшиеся данные будут добавлены в область «переполнения», что нормально.

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

Есть ли какие-либо ограничения на создание индексов со столбцом nvarchar (max) или что-либо, что платит за необходимость добавленияограничение по размеру?

Спасибо!

Answer 1

Строго говоря, типы MAX всегда будут немного медленнее, чем типы не-MAX, см. Сравнение производительности varchar (max) и varchar (N) . Но это различие никогда не видимо на практике, где оно просто становится шумом в общей производительности, управляемой IO.

Ваша главная забота не должна быть о производительности MAX по сравнению с не-MAX. Вы должны быть обеспокоены вопросом , возможно, в этом столбце будет храниться более 8000 байт? Если ответ положительный, даже если очень маловероятно, то ответ очевиден : используйте тип MAX, больший риск преобразования этого столбца в тип MAX не стоит незначительного выигрыша в производительности для типов, не являющихся MAX.

Другие вопросы (возможность индексировать этот столбец, недоступность операций индекса ONLINE для таблиц со столбцами MAX) уже были решены ответом Дениса.

Кстати, информация о столбцах размером более 4 КБ с оставшимися данными в области переполнения неверна. Правильная информация в Организация таблиц и индексов :

ROW_OVERFLOW_DATA Распределительная единица

Для каждого раздела, используемого таблицей (куча или кластеризованная таблица), индекс или индексированное представление, есть один ROW_OVERFLOW_DATA блок выделения. Эта единица распределения содержит ноль (0) страницы до строки данных с переменной длина столбцов (varchar, nvarchar, varbinary, или sql_variant) в Единица размещения IN_ROW_DATA превышает ограничение размера строки 8 КБ. Когда размер ограничение достигнуто, SQL Server перемещает столбец с наибольшим Ширина от этой строки до страницы в ROW_OVERFLOW_DATA блок выделения. 24-байтовый указатель на эти данные вне строки поддерживается на исходной странице.

То есть не столбцы размером более 4 КБ, это строки, которые не помещаются в свободное место на странице и не являются «оставшимися», это весь столбец.

Answer 2

индекс не может быть создан для столбца размером более 900 байт. Столбцы с типами данных больших объектов (LOB) ntext, text, varchar(max), nvarchar (max), varbinary (max), xml или image нельзя указывать в качестве ключевых столбцов для индекса

однако вы можете использовать included columns

Разрешены все типы данных, кроме текста, текста и изображения. Индекс должен быть создан или перестроен в автономном режиме (ONLINE = OFF), если какой-либо из указанных неключевых столбцов относится к типам данных varchar (max), nvarchar (max) или varbinary (max).

Answer 3

Выбор nvarchar (max) также может повлиять на оптимизацию плана выполнения, автоматически адаптируемую механизмом сервера SQL.