Поскольку требования к хранилищу для поля Varchar основаны на фактической длине введенной строки, что будет недостатком определения каждого поля Varchar как максимально возможного: Varchar (65535)? Ну, кроме 1 дополнительного байта для максимальных полей > 255 символов?
[Хранение Reqts для строк длины L: L + 1 байт, если значения столбца требуют 0 - 255 байт, L + 2 байта, если значения могут потребовать более 255 байт]
Спасибо!
Я думаю, что длина столбцов varchar не только для хранения. Они касаются семантики данных.
т.е. указание столбца name как varchar(100) означает, что имена, хранящиеся в вашей системе, не должны превышать 100 символов.
На стороне хранения вещей они должны быть одинаковыми. Хотя оценки размеров строк были бы более точными с определенной длиной на столбцах varchar, которые без них (без использования системы сбора статистики, содержащей распределение данных на размерах varchar).
Из документы - Границы таблицы и количества строк:
Каждая таблица (независимо от механизма хранения) имеет максимальный размер строки 65 535 байт. Двигатели хранения могут устанавливать дополнительные ограничения на этот предел, уменьшая эффективный максимальный размер строки.
Максимальный размер строки ограничивает число (и, возможно, размер) столбцов, потому что общая длина всех столбцов не может превышать этот размер. Например, для символов utf8 требуется до трех байтов на символ, поэтому для столбца CHAR (255) CHARACTER SET utf8 сервер должен выделять 255 × 3 = 765 байтов на каждое значение. Следовательно, таблица не может содержать более 65535/765 = 85 таких столбцов.
Хранение столбцов переменной длины включает байты длины, которые оцениваются по размеру строки. Например, столбец VARCHAR (255) CHARACTER SET utf8 принимает два байта для хранения длины значения, поэтому каждое значение может занимать до 767 байт.
Таким образом, определение одного столбца VARCHAR(65535) эффективно ограничивает вас одним столбцом в строке (при условии, что вы его заполнили).
Все это помимо того факта, что для некоторых типов данных такой большой размер совершенно неверен - если у вас есть столбец номера телефона, который может содержать локальные и международные номера, вы можете использовать поле VARCHAR для выполнения поэтому, но установив его на что-нибудь более 20, может быть бессмысленным (я щедр).
См. этот ответ от Билла Карвина, который также указывает возможные штрафы за производительность, если временные таблицы генерируются с ненужными длинными полями VARCHAR (чтобы преобразовать такие поля в CHAR и обратно - см. сообщение для подробностей).
Одна из возможных причин - улучшить совместимость с другими приложениями. Например, если у вас было приложение, в котором использовалось поле "product_no" длиной 100 символов, и вы хотели бы взаимодействовать с приложением, которое использовало аналогичное поле типа "model_no", длина которого составляла 40 символов, было бы больно. Любое product_nos в вашем приложении, длина которого превышает 40 символов, будет усечена, и вам нужно будет каким-то образом перевести их между приложениями.
Одна из причин заключается в том, что размер поля - это проверка введенных данных. Вы действительно хотите, чтобы кто-то ввел номер телефона на 1000 символов? Наличие слишком большого поля - это способ гарантировать, что мусор будет введен в вашу базу данных. У вас будут номера телефонов, которые говорят такие вещи (например, не принимаются случайным образом):
"поговорите только с большой блондинкой в передней части офиса"
вместо реального номера телефона или поля электронной почты, в котором содержатся примечания о клиенте, потому что у них нет поля примечаний? Это не работает так хорошо, когда вы пытаетесь отправить ему электронное письмо.
Широкие таблицы могут создавать проблемы в их собственных базах данных, так как вы можете столкнуться с непредвиденными ограничениями записи (вы можете создать таблицу, которая будет более широкой, чем на самом деле может быть сохранена в одной записи, иногда это приводит к неожиданным сбоям вставки) и проблемам с производительностью поскольку данные разделяются между страницами данных. Я знаю, что вы можете получить это из широких таблиц в SQL Server, и я не удивлюсь, если mysql столкнется с подобными проблемами. Эксперт mysql должен будет действительно решить это. Индексация также может быть проблемой с широкими полями. Механизм базы данных может быть менее склонным думать, что индекс полезен. Опять же, я не уверен, что mysql будет иметь эту проблему, но это то, что нужно исследовать. Я знаю, что это проблемы с использованием максимального размера поля для всего в SQL Server, у mysql могут быть эти проблемы или другие проблемы, которые SQL Server не делает.
Например, MEMORY Engine в MySQL не поддерживает VARCHAR-поля очень хорошо. Двигатель зарезервирует для каждой строки максимальное количество байтов, а не реально используемую длину. Поэтому, если вы определяете таблицу с одним столбцом VARCHAR (1000), тогда у вас будет использование памяти 1000 * 3 байта для каждой добавляемой строки, даже если это пустые строки.