Каковы последствия установки 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
источник