Влияние производительности на nvarchar (4000)?

Question

У меня есть столбец, который объявлен как nvarchar (4000), а 4000 - это ограничение SQL Server на длину nvarchar. он не будет использоваться в качестве ключа для сортировки строк.

Есть ли какие-либо последствия, о которых я должен знать, прежде чем устанавливать длину поля nvarchar в 4000?

Обновление

Я храню XML, точнее, XML-сериализованный объект. Я знаю, что это не выгодно, но нам, скорее всего, никогда не понадобится выполнять запросы к нему, и эта реализация значительно сокращает время разработки для определенных функций, которые мы планируем расширять. Я ожидаю, что в среднем данные XML будут иметь длину 1500 символов, но могут быть те исключения, в которых они могут быть длиннее 4000. Может ли это быть длиннее 4000 символов? Это может быть, но в очень редких случаях, если это когда-либо случится. Является ли эта миссия критической? Нет, совсем нет.

Answer 1

SQL Server имеет три типа хранилища: строчное, LOB и переполнение строк, см. Организация таблиц и индексов . Хранилище в ряду является самым быстрым для доступа. LOB и Row-Overflow похожи друг на друга, оба немного медленнее, чем в строке.

Если у вас есть столбец NVARCHAR (4000), он будет сохранен в строке, если это возможно, если нет, он будет сохранен в хранилище с переполнением строк. Наличие такого столбца не обязательно указывает на будущие проблемы с производительностью, но напрашивается вопрос: почему nvarchar (4000)? Ваши данные, вероятно, всегда будут иметь длину около 4000 символов? Может ли это быть 4001, как ваше приложение справится с этим в этом случае? Почему не nvarchar (макс)? Вы измерили производительность и обнаружили, что nvarchar (max) слишком медленный для вас?

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

Обновление

Для XML используйте тип данных XML . Он имеет много преимуществ перед varchar или nvarchar, например, тот факт, что он поддерживает XML-индексы , он поддерживает XML-методы и может фактически проверять XML на соответствие определенной схеме или, по крайней мере, для правильного соответствия XML.

XML будет храниться в хранилище больших объектов вне строки.

Даже если данные не в формате XML, я все равно рекомендовал бы хранилище больших объектов (nvarchar (max)) для чего-то, имеющего длину 1500. С извлечением данных, сохраненных в больших объектах, связаны затраты, но стоимость более чем компенсирована составив таблицу уже . Ширина строки таблицы является основным фактором производительности, поскольку более широкие таблицы занимают меньше строк на страницу, поэтому любая операция, которая должна сканировать диапазон строк или всю таблицу, должна извлекать больше страниц в память, и это проявляется в стоимость запроса (на самом деле движущий фактор общей стоимости). Хранимый столбец LOB только увеличивает размер строки на ширину «идентификатора страницы», которая, если я правильно помню, составляет 8 байт, так что вы можете получить намного лучшую плотность строк на странице, что ускоряет запросы.

Answer 2

Вы уверены, что вам действительно понадобится до 4000 символов? Если 1000 является практическим верхним пределом, почему бы не установить его на это? И наоборот, если вы, вероятно, получите более 4000 байтов, вам нужно взглянуть на nvarchar (max).

Мне нравится «поощрять» пользователей не использовать свободное место на диске слишком свободно. Чем больше места требуется для хранения данной строки, тем меньше места вы можете хранить на странице, что потенциально приводит к увеличению дискового ввода-вывода при чтении или записи таблицы. Несмотря на то, что хранится только столько байтов данных, сколько необходимо (т.е. не полных 4000 на строку), всякий раз, когда вы получаете чуть более 2000 символов данных nvarchar, у вас будет только одна строка на страницу, и производительность действительно может страдать.

Это, конечно, предполагает, что вам нужно хранить данные в формате Unicode (двухбайтовые), и что у вас есть только один такой столбец на строку. Если нет, перейдите к varchar.

Answer 3

Вам обязательно нужен nvarchar или вы можете пойти с varchar? Ограничение относится в основном к серверу sql 2k. Вы используете 2k5 / 2k8?