varchar 255 что это
Почему я должен выбирать любую другую длину, чем 255 для varchar в MySQL?
Я знаю разницу между CHAR и VARCHAR,
Это кажется бессмысленным для меня, потому что фактическое используемое пространство зависит от значения, хранящегося в базе данных.
1) Хорошо установить для всех моих varchar значение 255 2) Почему вы хотите указать любую другую длину?
ОТВЕТЫ
Ответ 1
1) Если вы не хотите ограничивать максимальный размер хранимого varchar, тогда да, это нормально. Это сказано.
2) Во многих случаях вы хотите установить верхний предел для размера varchar. Допустим, вы сохраняете список рассылки и имеете ограниченное пространство для адресной строки. Установив верхний предел для вашего поля адреса, вы теперь разрешаете базе данных обеспечивать максимальную длину адресной строки для вас.
Ответ 2
Типы CHAR и VARCHAR аналогичны, но отличаются тем, как они сохраняются и извлекаются. Начиная с MySQL 5.0.3, они также отличаются максимальной длиной и сохраняются ли сохраняющиеся пробелы.
Типы CHAR и VARCHAR объявляются с длиной, которая указывает максимальное количество символов, которые вы хотите сохранить. Например, CHAR (30) может содержать до 30 символов.
Длина столбца CHAR фиксируется на длину, которую вы объявляете при создании таблицы. Длина может быть любым значением от 0 до 255. Когда значения CHAR сохраняются, они заполняются пробелами с заданной длиной. Когда извлекаются значения CHAR, конечные пробелы удаляются.
Значения в столбцах VARCHAR представляют собой строки переменной длины. Длина может быть указана как значение от 0 до 255 до MySQL 5.0.3 и от 0 до 65535 в 5.0.3 и более поздних версиях. Эффективная максимальная длина VARCHAR в MySQL 5.0.3 и более поздних версиях зависит от максимального размера строки (65 535 байт, которая распределяется между всеми столбцами) и используемого набора символов.
В отличие от CHAR значения VARCHAR сохраняются в виде однобайтового или двухбайтового префикса длины плюс данные. Префикс длины указывает количество байтов в значении. Столбец использует один байт длины, если для значений не более 255 байт, байты длиной 2 байта, если для значений может потребоваться больше 255 байтов.
Ответ 3
CHAR Vs VARCHAR
CHAR используется для переменной размера фиксированной длины.
VARCHAR используется для переменной переменной длины.
Изменить
Ответ 4
Итак, если ваша таблица не имеет других полей, которые являются varchar, text или blob; вы можете использовать char и сделать свою таблицу статичной. Таким образом, они быстрее.
Ответ 5
1) Технически это прекрасно, потому что поля создаются с длиной всего 1 или 2 байта в начале. Впоследствии они будут расти по мере необходимости.
2) Сказав, что, несмотря на то, что хорошие принципы проектирования предполагают, что вы задаете длины полей соответствующим образом, чтобы: а) если кто-то проходит через схему таблицы и пытается определить, сколько данных хранится в определенных полях, они могут видеть, что определенные поля будет содержать меньше данных, чем другие, и b) вы можете предотвратить небольшое количество дополнительной работы, выполняемой механизмом базы данных, поскольку оно должно усекать меньше места из поля VARCHAR (10), чем VARCHAR (255) во время вставки.
Подробнее об этом можно узнать здесь:
Ответ 6
Я читал в другом месте, что varchar имеет производительность по сравнению с char, когда вы запускаете выборки по столбцам, определенным с ними. Итак, возможно, вы хотите выбрать char, если вы точно знаете, что поле всегда будет определенной длины, и у вас проблемы с производительностью.
Ответ 7
Посмотрите на такие базы данных, как sqlite, которые хранят все как текст для доказательства того, что это уже не имеет значения.
Ответ 8
Основное различие между этими двумя типами значений возникает при выполнении сравнения между строками.
В столбце CHAR, длина которого предопределена, вам придется «запускать» весь путь по длине столбца, а в столбце VARCHAR вам нужно «запустить» всю дорогу по длине значения и а не длина столбца, что в большинстве случаев намного быстрее.
Поэтому длина значения, которая меньше длины поля, будет быстрее сравниваться, если она хранится в поле VARCHAR.
Ответ 9
Но я хотел знать, что такое пупс, у которого есть опция для длины варчара, например. VARCHAR (50), VARCHAR (100), VARCHAR (255)
Это кажется бессмысленным для меня, потому что фактическое используемое пространство зависит от значения, хранящегося в базе данных.
Задание, например, VARCHAR (5) вместо VARCHAR (500) может дать вам лучшую производительность в некоторых случаях, например. для операций, которые используют временные таблицы в памяти.
Другим случаем является ограничение длины столбца на соответствие требованиям домена (когда ваше значение не должно быть больше некоторого максимума. Пример: полное доменное имя в DNS не может превышать длину 253 символов)
Типы char и varchar (Transact-SQL)
Символьные типы данных имеют фиксированный (char) или переменный (varchar) размер. Начиная с SQL Server 2019 (15.x) при использовании параметров сортировки с поддержкой UTF-8 эти типы данных хранят весь диапазон символьных данных Юникод и используют кодировку UTF-8. Если указаны параметры сортировки без поддержки UTF-8, эти типы данных хранят только подмножество символьных данных, поддерживаемых соответствующей кодовой страницей указанных параметров сортировки.
Аргументы
char [ ( n ) ] — строковые данные фиксированного размера. n определяет размер строки в байтах и должно иметь значение от 1 до 8000. Для однобайтовых кодировок, таких как Latin, размер при хранении равен n байт, а количество хранимых символов — тоже n. Для многобайтовых кодировок размер при хранения тоже равен n байт, но количество хранимых символов может быть меньше n. Синонимом по стандарту ISO для типа char является character. Дополнительные сведения о кодировках см. в статье Однобайтовые и многобайтовые кодировки.
varchar [ ( n | max ) ] — строковые данные переменного размера. Используйте значение n для определения размера строки в байтах (допускаются значения от 1 до 8000) или используйте max для указания предельного размера столбца вплоть до максимального размера хранилища, что составляет 2^31-1 байт (2 ГБ). Для однобайтовых кодировок, таких как Latin, размер при хранении равен n байт + 2 байта, а количество хранимых символов — n. Для многобайтовых кодировок размер при хранении тоже равен n байт + 2 байта, но количество хранимых символов может быть меньше n. Синонимами по стандарту ISO для типа varchar являются типы charvarying или charactervarying. Дополнительные сведения о кодировках см. в статье Однобайтовые и многобайтовые кодировки.
Remarks
Часто ошибочно считают, что в типах данных CHAR(n) и VARCHAR(n) число n указывает на количество символов. Однако на самом деле число n в CHAR(n) и VARCHAR(n) — это длина строки в байтах (0–8000). n никогда не определяет количество хранимых символов. То же самое верно и в отношении типов NCHAR(n) и NVARCHAR(n). Причина этого заблуждения в том, что при использовании однобайтовых кодировок размер данных типов CHAR и VARCHAR при хранении равен n байт, а количество символов — тоже n. Однако в случае с многобайтовыми кодировками, такими как UTF-8, в старших диапазонах Юникода (128–1 114 111) один символ занимает два или несколько байтов. Например, в столбце, определенном как CHAR(10), Компонент Database Engine может хранить 10 символов, использующих однобайтовую кодировку (диапазон Юникода 0–127), но меньше 10 символов при использовании многобайтовой кодировки (диапазон Юникода 128–1 114 111). Дополнительные сведения о хранении символов Юникода и их диапазонах см. в разделе Различия в хранении UTF-8 и UTF-16.
Если значение n в определении данных или инструкции объявления переменной не указано, длина по умолчанию равна 1. Если значение n не указано при использовании функций CAST и CONVERT, длина по умолчанию равна 30.
Объектам, в которых используются типы данных char и varchar, назначаются параметры сортировки базы данных по умолчанию, если только иные параметры сортировки не назначены с использованием предложения COLLATE. Параметры сортировки контролируют кодовую страницу, используемую для хранения символьных данных.
В SQL Server многобайтовые кодировки включают:
Если у вас есть сайты, поддерживающие несколько языков, примите к сведению следующие рекомендации:
Если вы используете char или varchar, мы рекомендуем:
Если SET ANSI_PADDING равно OFF при выполнении CREATE TABLE или ALTER TABLE, столбец char, определенный как NULL, обрабатывается как varchar.
Для каждого ненулевого столбца varchar(max) или nvarchar(max) требуется 24 байта дополнительного фиксированного выделения, которые учитываются в максимальном размере строки в 8060 байт во время операции сортировки. Это может создать неявное ограничение в ряде ненулевых столбцов varchar(max) или nvarchar(max), которые могут быть созданы в таблице. При создании таблицы или во время вставки данных не возникает особых ошибок (кроме обычного предупреждения о том, что максимальный размер строки превышает максимально допустимое значение в 8060 байт). Такой размер строки может вызывать ошибки (например, ошибку 512) во время некоторых обычных операций, таких как обновление ключа кластеризованного индекса, или сортировки полного набора столбцов, которая происходит только во время выполнения операции.
Преобразование символьных данных
При преобразовании символьного выражения в символьный тип данных другой длины значения, слишком длинные для нового типа данных, усекаются. Тип uniqueidentifier считается символьным типом, используемым при преобразовании из символьного выражения, поэтому на него распространяются правила усечения при преобразовании в символьный тип. См подраздел «Примеры» ниже.
Преобразование кодовых страниц поддерживается для типов данных char и varchar, однако поддержка типа данных text не предусмотрена. Как и в ранних версиях SQL Server, о потере данных во время преобразования кодовых страниц не сообщается.
Символьные выражения, которые преобразуются в приближенный тип данных numeric, могут содержать необязательную экспоненциальную нотацию (символ e нижнего регистра или E верхнего регистра, за которым следуют необязательный знак плюс (+) или минус (–) и число).
Символьные выражения, преобразуемые в точный тип данных numeric, должны состоять из цифр, десятичного разделителя и необязательного знака плюс (+) или минус (–). Начальные пробелы не учитываются. Разделители в виде запятой запрещены (например, десятичный разделитель в числе 123 456,00).
Кроме того, символьные выражения, преобразуемые в типы данных money или smallmoney, могут содержать необязательный десятичный разделитель и обозначение валюты. Разрешаются разделители в виде запятой, например 123 456,00 руб.
Примеры
A. Отображение значения по умолчанию n при использовании в объявлении переменной
Б. Отображение значения по умолчанию n при использовании функций CAST и CONVERT с типом данных varchar
В. Преобразование данных для отображения
В следующем примере два столбца преобразуются в символьные типы, после чего к ним применяется стиль, применяющий к отображаемым данным конкретный формат. Тип money преобразуется в символьные данные. К нему применяется стиль 1, отображающий значения с запятыми между каждой группой из трех цифр, отсчитывая влево от десятичной точи, и каждой группой из двух цифр, отсчитывая вправо от десятичной точки. Тип datetime преобразуется в символьные данные. К нему применяется стиль 3, отображающий данные в формате дд/мм/гг. В предложении WHERE тип money приводится к символьному типу для выполнения операции сравнения строк.
Г. Преобразование данных uniqueidentifier
Следующий пример показывает усечение данных, когда значение является слишком длинным для преобразования в заданный тип данных. Так как тип данных uniqueidentifier ограничен 36 символами, все символы, выходящие за пределы этой длины, будут усечены.
Типы полей в MySQL
В этой статье мы освятим очень важный вопрос, связанный с тем, какие типы полей в таблицах предоставляет нам MySQL. Ведь не секрет, что записи в таблицах должны соответствовать этим типам. И каждая ячейка записи должна удовлетворять определённым условиям, которые как раз и задаются типом поля в MySQL.
Давайте с Вами по порядку разберём все типы полей в MySQL
1. VARCHAR. Это тип является строковым, причём строкой переменной длины от 0 до 255 символов.
3. TEXT (BLOB). Это обычный строковый тип, в котором максимальная длина составляет 65535 символов. Идеальный вариант для хранения текстов статей.
4. DATE. Этот тип отвечает за дату. Формат следующий: «YYYY-MM-DD«. Например, такое значение будет удовлетворять этому полю: «2011-01-02«.
11. DECIMAL. Редко используемый тип даных, но тем не менее. Это число, похожее на тип DOUBLE, но хранится оно в виде строки. И, фактически, интервал допустимых значений определяется наличием знака «—» и «.«. Если эти знаки отсутсвуют, то допустимый интервал такой же, как и у DOUBLE.
12. DATETIME. Тип данных, отвечающих за хранение даты и времени. Формат следующий: «YYYY-MM-DD HH:MM:SS«.
13. TIMESTAMP. Определённая временная метка, которая может иметь один из следующих форматов: «YYYYMMDDHHMMSS«, «YYMMDDHHMMSS«, «YYYYMMDD«, «YYMMDD«.
14. TIME. Простой тип, отвечающий за время в формате: «HH:MM:SS«.
15. YEAR. Тип, отвечающий за год в одном из двух форматов: «YY«, «YYYY«.
16. CHAR. Строка фиксированной длины. Диапазон состовляет от 0 до 255 символов. При хранении данный тип добавляет к концу строки количество пробелов до заданного размера.
17. TINYTEXT (TINYBLOB). Текст с длиной от 0 до 255 символов.
18. MEDIUMTEXT (MEDIUMBLOB). Текст с длиной от 0 до 16777215 символов.
19. LONGTEXT (LONGBLOB). Текст с длиной от 0 до 4294967295 символов.
20. ENUM. Этот тип содержит список значений. Другими словами, значение соответствующей ячейки записи должно быть выбрано из списка допустимых строковых значений (аналог radiobutton). Максимальное количество значений 65535.
Вот мы и познакомились со всеми типами полей в MySQL. Как и обещал, рассказываю, как выбрать, какое число будет использоваться: положительное или отрицательное. Для этого есть специальный атрибут UNSIGNED, который если стоит, то число положительное, а если его нет, то число может быть как положительным, так и отрицательным. Впрочем, потом Вы всё поймёте, а пока просто примите это к сведению.
Разумеется, всё это запоминать не нужно. И давайте я сейчас Вам перечислю типы, которые используются очень часто и которые многократно использовал я сам:
Как видите, типов полей в MySQL очень много, но используются активно всего 5-6, поэтому всё очень и очень просто.
MySQL: Зачем использовать VARCHAR (20) вместо VARCHAR (255)?
В MYSQL вы можете выбрать длину поля типа VARCHAR. Возможные значения: 1-255.
Но каковы его преимущества, если вы используете VARCHAR (255), который является максимальным, а не VARCHAR (20)? Насколько я знаю, размер записей зависит только от реальной длины вставленной строки.
size (bytes) = length + 1
Итак, если у вас есть слово «Пример» в поле VARCHAR (255), оно будет иметь 8 байтов. Если у вас есть это в поле VARCHAR (20), у него тоже будет 8 байтов. В чем разница?
Надеюсь, ты поможешь мне. Спасибо заранее!
ОТВЕТЫ
Ответ 1
Короче говоря, нет большой разницы, если вы не переберете размер 255 в вашем VARCHAR, который потребует другого байта для префикса длины.
Длина указывает больше ограничений на данные, хранящиеся в столбце, чем что-либо еще. Это по сути ограничивает размер хранилища MAXIMUM для столбца. ИМХО, длина должна иметь смысл в отношении данных. Если вы сохраняете Social Security #, нет смысла устанавливать длину до 128, даже если это не стоит вам ничего в памяти, если все, что вы на самом деле сохраняете, является SSN.
Ответ 2
Существует много веских причин для выбора значения, которое меньше максимального, не связанного с производительностью. Установка размера помогает указать тип данных, которые вы храните, а также также может действовать как форма проверки в последний раз.
Например, если вы храните британский почтовый индекс, вам нужно всего 8 символов. Установка этого ограничения помогает очистить тип данных, которые вы храните. Если вы выбрали 255 символов, это просто смутит вопросы.
Ответ 3
Я не знаю о mySQL, но в SQL Server он позволит вам определять такие поля, чтобы общее количество используемых байтов было больше, чем общее количество байтов, которые могут быть фактически сохранены в записи. Это плохо. Рано или поздно вы получите строку, в которой достигнут предел, и вы не можете вставить данные.
Намного лучше спроектировать структуру базы данных для рассмотрения ограничений размера строк.
Кроме того, да, вы не хотите, чтобы люди помещали 200 символов в поле, где максимальное значение должно быть 10. Если это так, это почти всегда плохие данные.
Вы говорите, я могу ограничить это на уровне приложения. Но данные не попадают в базу данных только из одного приложения. Иногда его используют несколько приложений, иногда данные импортируются и иногда фиксируются вручную из окна запроса (обновляйте все записи, чтобы добавить, например, 10% к цене). Если какой-либо из этих других источников данных не знает о правилах, введенных вами в приложение, у вас будут плохие, бесполезные данные в вашей базе данных. Целостность данных должна выполняться на уровне базы данных (что не мешает вам также проверять, прежде чем пытаться ввести данные), или у вас нет целостности. Плюс мой опыт заключается в том, что люди, которые слишком ленивы для разработки своей базы данных, часто слишком ленивы, чтобы фактически ввести ограничения в приложение и вообще не проверять целостность данных.
Ответ 4
Ну, если вы хотите разрешить большую запись или, возможно, ограничить размер записи.
Например, у вас может быть first_name как VARCHAR 20, но, возможно, street_address как VARCHAR 50 с 20 может быть недостаточно места. В то же время вы можете контролировать, насколько велика эта ценность.
Другими словами, вы установили максимальный уровень того, насколько значительным может быть определенное значение, теоретически, чтобы предотвратить слишком большую величину таблицы (и, возможно, записей индекса/индекса).
Вы можете просто использовать CHAR, который также является фиксированной шириной, но в отличие от VARCHAR, который может быть меньше, CHAR заполняет значения (хотя это делает более быстрый доступ SQL.
Ответ 5
С точки зрения производительности базы данных, я не думаю, что будет какая-то разница.
Однако, я думаю, что многие решения по длине использования сводятся к тому, что вы пытаетесь выполнить и документируете систему, чтобы принимать только те данные, которые ей нужны.
Ответ 6
Существует семантическая разница (и я считаю, что единственное различие): если вы попытаетесь заполнить 30 непространственных символов в varchar (20), это приведет к ошибке, тогда как для varchar (255) это будет успешным. Таким образом, это прежде всего дополнительное ограничение.
varchar(max)-varchar(max) и в продакшн
Недавно поучаствовал в дискуссии на тему влияния на производительность указания длины в столбцах с типом nvarchar. Доводы были разумны у обеих сторон и поскольку у меня было свободное время, решил немного потестировать. Результатом стал этот пост.
Спойлер – не всё так однозначно.
Все тесты проводились на SQL Server 2014 Developer Edition, примерно такие же результаты были получены и на SQL Server 2016 (с небольшими отличиями). Описанное ниже должно быть актуально для SQL Server 2005-2016 (а в 2017/2019 требуется тестирование, поскольку там появились Adaptive Memory Grants, которые могут несколько исправить положение).
Нам понадобятся – хранимая процедура от Erik Darling sp_pressure_detector, которая позволяет получить множество информации о текущем состоянии системы и SQL Query Stress – очень крутая open-source утилита Adam Machanic/Erik Ejlskov Jensen для нагрузочного тестирования MS SQL Server.
О чём вообще речь
В SQL Server 2012/2014 есть ещё одна забавная шутка с sort spills. Даже если вы используете тип char/nchar – это не гарантирует отсутствие spill’ов в tempdb. MS признала проблему в оптимизаторе, когда он выделял слишком мало памяти для сортировки, даже если количество строк было оценено верно.
Включаем документированный флаг трассировки (НЕ ДЕЛАЙТЕ ЭТОГО НА ПРОДЕ БЕЗ НЕОБХОДИМОСТИ):
Выводы
С осторожностью используйте сортировку в своих запросах, там где у вас есть колонки (n)varchar. Если сортировка всё же нужна, крайне желательно, чтобы по колонке сортировки был индекс.
Учтите, что чтобы получить сортировку совсем необязательно явно использовать order by – её появление возможно и при merge join’ах, например. Та же проблема с выделением памяти возможна и при hash join’ах, например, вот с varchar(max):
Выделено 2.5 ГИГАБАЙТА памяти, используется 25 мегабайт!
Главный для меня вывод: размер колонки (n)varchar – ВАЖЕН! Если размер слишком маленький – возможны spill’ы в tempdb, если слишком большой – возможны слишком большие запросы памяти. При наличии сортировок разумным будет объявлять длину varchar как средняя длина записи * 2, а в случае SQL Server 2012/2014 — даже больше.
Неожиданный для меня вывод: varchar(max), содержащий меньше 8000 символов, реально работает медленнее, при фильтрах по нему. Пока не знаю как это объяснить — буду копать ещё.
Бонусный вывод для меня: уже почти нажав «опубликовать» я подумал, что ведь и с varchar(max) можно испытать проблему «маленького varchar’a». И правда, при хранении в varchar(max) больше чем 4000 символов (2000 для nvarchar) — сортировки могут стать проблемой.
Почему в самом начале я написал, что не всё так однозначно? Потому что, например, на моём домашнем ноуте с полумёртвым диском, spill’ы в tempdb при сортировке «маленьких» varchar приводили к тому, что такие запросы выполнялись на ПОРЯДКИ медленнее, чем аналогичные запросы с varchar(max). Если у вас хорошее железо, возможно, они не станут такой проблемой, но забывать о них не стоит.
Что было бы ещё интересно — посмотреть есть ли какие-то проблемы из-за слишком больших/маленьких размеров varchar’ов в других СУБД. Если у вас есть возможность проверить — буду рад, если поделитесь.
Маленький бонус
Отловить такие проблемы с помощью кэша планов запросов, к сожалению, не получится. Вот примеры планов из кэша: никаких предупреждений в них, увы, нет.