Каковы последствия установки varchar (8000)?

22

Поскольку varchar занимает дисковое пространство, пропорциональное размеру поля, есть ли какая-то причина, по которой мы не всегда должны определять varchar как максимум, например, varchar(8000)на SQL Server?

При создании таблицы, если я вижу, что кто-то делает, varchar(100)я должен сказать им, что вы не правы, вы должны сделать varchar(8000)?

sql-server varchar Александр Левчук
источник
Я думаю, что здесь мы должны различать использование в создании таблицы и использование в объявлениях параметров хранимых процедур. Для второго толкования см. Мой вопрос dba.stackexchange.com/questions/1772/…
bernd_k

Ответы:

18
  • Длина - это ограничение данных (например, CHECK, FK, NULL и т. Д.)
  • Производительность, когда строка превышает 8060 байт
  • Не может иметь уникальное ограничение или индекс (ширина ключевого столбца должна быть <900)
  • По умолчанию установлено значение SET ANSI PADDING ON = потенциальная возможность сохранения большого количества конечных пробелов.
  • SQL Server будет предполагать, что средняя длина операции сортировки составляет 4000, и для этого выделяется память (нужно найти ссылку, чтобы сделать резервную копию, но ржавеет, пока я делаю :-)

Резюме: не делай этого.

ГБН
источник
Производительность, когда строка превышает 8060 байт . Это относится к фактически используемым байтам, а не к максимально допустимым байтам?
bernd_k
@bernd_k: 8060 = наибольшее количество данных для одной строки, которое поместится на одной странице 8192. Включить заголовок строки. Остаток (132 байта) = издержки страницы
gbn
Это означает, что производительность уменьшается, когда на самом деле используется больший размер, а не тот факт, что его использование разрешено.
bernd_k
@bernd_k: любое снижение производительности вызвано 1. выделением памяти для сортировок и т. д. 2. переполнением строки (> 8060 байт). Факт наличия 10 символов в каждом varchar (8000) не имеет значения, пока эти условия не будут выполнены (SQL сообщит о потенциальных ошибках позже для ключей индекса)
gbn
Стоит ли сортировать таблицу со столбцом varchar (100), заполненным полями длиной 100 байт, потому что сортировка предполагает в среднем 50 символов?
bernd_k
7

Предполагая, что вы имеете в виду SQL Server, я могу подумать об одном.

Существует ограничение на размер (8 КБ) строки в таблице, и SQL позволяет определять поля varchar, которые теоретически могут превышать этот предел. Таким образом, пользователь может получить ошибки, если он поместит слишком много данных в поле, связанное с этим.

Начиная с SQL 2K8, вы можете превысить это ограничение, но это влияет на производительность .

Кроме того, существует полная проверка разумности ограничения размера на то, как вы ожидаете, что данные будут выглядеть. Если вам нужно поле неограниченной длины, почему бы не использовать текст или текст?

JohnFx
источник
Таким образом, типы данных text и ntext хранятся таким образом, что это не влияет на производительность?
Чад
Эти типы вносят незначительный вклад в ограничение размера строки в 8 КБ в таблице, потому что фактические данные хранятся в отдельной таблице под обложками, а не в ряд с остальными столбцами. Это все еще влияет на производительность, но по другим причинам. Есть также ограничения на поддержку функций в этих полях по сравнению с varchar и nvarchar
JohnFx
text и ntext не рекомендуется в пользу varchar (max).
Фил Хелмер
3

Наверняка это зависит от того, какая информация хранится в поле?

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

Если теоретически нет максимальной длины, то я бы спросил, почему будет использоваться varchar.

Тоби
источник
3

В контексте баз данных Oracle я узнал, что всегда использование наименьшего размера поля для столбцов базы данных имеет один подводный камень.

При перемещении данных с помощью импорта-импорта из базы данных с однобайтовым сопоставлением в базу данных с многобайтовым сопоставлением (например, Oracle XE) длина в байтах может увеличиться, и импорт данных в таблицы, созданные при импорте, завершится неудачно. Конечно, у Oracle есть возможность определять длину varchar2 как char или как байты.

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

Обсуждаемый вариант с 20% - 100% неиспользуемым полем.

bernd_k
источник