Как длинные столбцы влияют на производительность и использование диска?

В нашем текущем проекте слишком часто случается, что нам нужно расширить столбцы на пару символов. От varchar(20)до varchar(30)и так далее.

На самом деле, насколько это действительно важно? Насколько хорошо это оптимизировано? Какое влияние дает разрешение 100, 200 или даже 500 символов на обычные поля ввода? В письме может быть только 320 символов, так что хорошо - здесь есть хороший предел. Но что я получу, если я установлю его на 200, потому что я не ожидаю более длинные адреса электронной почты, чем это.

Обычно в наших таблицах будет не более 100 000 строк и не более 20 или 30 таких столбцов.

Сейчас мы используем SQL Server 2008, но было бы интересно узнать, как разные БД решают эти проблемы.

В случае, если влияние очень низкое - как я и ожидал, это помогло бы получить несколько хороших аргументов (подкрепленных ссылками?), Чтобы убедить моего администратора баз данных, что эта паранойя длинных полей не является действительно необходимой.

Если это так, я здесь, чтобы учиться :-)

Конкретный ответ на ваш вопрос (по крайней мере, для Oracle и, возможно, для других баз данных) заключается в том, что длина поля не имеет значения, только длина данных. Однако это не должно использоваться в качестве определяющего фактора относительно того, устанавливать ли поле на максимально допустимую длину или нет. Вот некоторые другие вопросы, которые вы должны рассмотреть, прежде чем увеличивать размеры полей.

Форматирование Любой клиентский инструмент, который форматирует данные на основе размера полей, потребует особых соображений по форматированию. Например, в Oracle SQL * Plus по умолчанию отображается максимальный размер столбцов Varchar2, даже если длина данных составляет всего один символ. Сравнить ...

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

Неверные данные Длина поля обеспечивает дополнительный механизм , чтобы поймать / предотвратить плохие данные. Интерфейс не должен пытаться вставить 3000 символов в 100-символьное поле, но если это поле определено в 4000 символов, это может произойти. Ошибка не может быть обнаружена на этапе ввода данных, но система может столкнуться с проблемами в дальнейшем, когда другое приложение пытается обработать данные и заклинило. Например, если вы позже решите проиндексировать поле в Oracle, вы превысите максимальную длину ключа (в зависимости от размера блока и конкатенации). Видеть…

create index i1 on f1(a);

Память Если клиентское приложение выделяет память, используя максимальный размер, приложение выделяет значительно больше памяти, чем необходимо. Особые соображения должны быть сделаны, чтобы избежать этого.

Документация Размер поля обеспечивает другую точку данных документации о данных. Мы можем назвать все таблицы t1, t2, t3 и т. Д., А также все поля f1, f2, f3 и т. Д., Но, указав значимые имена, мы лучше поймем данные. Например, если в таблице адресов для компании с клиентами в США есть поле с именем State, состоящее из двух символов, мы ожидаем, что в нем будет использоваться двухбуквенное сокращение состояния. С другой стороны, если поле содержит сто символов, мы можем ожидать, что в поле будет указано полное имя состояния.

Несмотря на все сказанное, представляется разумным быть готовым к изменениям. Тот факт, что все названия ваших продуктов сегодня соответствуют 20 символам, не означает, что они всегда будут. Не идите за борт и наберите 1000, но оставьте место для возможного расширения.

Вот хорошая отправная точка для вас.

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

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

Вот хорошая ссылка на выбор типов данных: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

Переход с varchar (20) на varchar (30) может показаться чем-то небольшим, но вам нужно больше понимать, как работают структуры баз данных, чтобы знать о потенциальных проблемах. Например, обращение к varchar (30) может заставить вас преодолеть переломный момент в ваших столбцах (если все 30 байтов будут использованы), будучи в состоянии хранить на одной странице (менее 8060 байтов). Это приведет к увеличению используемого дискового пространства, снижению производительности и даже дополнительным расходам журналов транзакций.

Вот ссылка на структуры базы данных: http://technet.microsoft.com/en-us/sqlserver/gg313756.aspx

Вот один для разбиения страницы и регистрации trx: http://sqlskills.com/BLOGS/PAUL/post/How-exорого-are-page-splits-in-terms-of-transaction-log.aspx

НТН

Я думал, что поделюсь другим интересным моментом, который я нашел в следующем вопросе:

/programming/148398/are-there-any-disadvantages-to-always-using-nvarcharmax

Оригинальный ответ от: Ник Кавадиас

Причина НЕ использовать максимальные или текстовые поля заключается в том, что вы не можете выполнить [онлайн перестроения индекса] [1], т.е. REBUILD WITH ONLINE = ON даже с SQL Server Enterprise Edition.

[1]: http://msdn.microsoft.com/en-us/library/ms188388%28SQL.90%29.aspx "Перестроение индекса в сети"

Я бы посчитал это большим недостатком при произвольном добавлении столбцов n / varchar (max), и, в соответствии с MS Site, это ограничение в отношении перестроений индексов в режиме онлайн сохраняется в SQL Server 2008, 2008 R2 и Denali; так что это не относится к SQL Server 2005.

Спасибо джефф

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

Я обнаружил, что презентации на SQLWorkshops.com заставляют задуматься: в этой презентации рассказывается о случае, когда сортировка по заказу перетекает в базу данных tempdb, поскольку для полей char / varchar выделяется недостаточно памяти.

http://webcasts2.sqlworkshops.com/webcasts.asp

Эта веб-трансляция также была представлена ​​в виде статьи на следующем веб-сайте:

http://www.mssqltips.com/tip.asp?tip=1955

Обратите внимание, что в этой презентации сортируемый столбец не является столбцом char / varchar, но объем пространства, выделенного для столбца varchar в памяти, в некоторых случаях влияет на производительность запроса.

ВКЛЮЧИТЬ ANSI_PADDING?

Вы заканчиваете большим количеством пробелов ...

Это касается только дискового пространства и длины символов. Конечно, поиск по типам данных char и индексам по этим типам данных будет выполняться медленнее, чем целочисленные, но это другое обсуждение.

Тип данных Varchar является «переменным» типом данных, поэтому, если вы установите ограничение varchar (500), то это максимальная длина символа для этого поля. Минимальная длина может быть от 0 до 500. С другой стороны, заявленное дисковое пространство будет другим для полей длиной 10, 30 или 500 символов.

Иногда я делал тест для типа данных varchar (800) и для нулевых значений, у меня было использовано 17 байт, и для каждого вставленного символа добавлялся еще один байт. Например, строка из 400 символов содержала 417 байт на диске.

Я не думаю, что есть какая-либо разница между таблицами, созданными с помощью столбцов varchar (20) или varchar ((8000), поскольку фактическая максимальная длина составляет <= 20.

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