MySQL: большой VARCHAR против текста?

Question

MySQL: большой VARCHAR против текста?

720

У меня есть таблица сообщений в MySQL, которая записывает сообщения между пользователями. Помимо типичных идентификаторов и типов сообщений (все целые типы), мне нужно сохранить фактический текст сообщения как VARCHAR или TEXT. Я устанавливаю front-end limit из 3000 символов, что означает, что сообщения никогда не будут вставляться в db дольше, чем это.

Есть ли обоснование для перехода с VARCHAR (3000) или TEXT? Там что-то о том, как просто писать VARCHAR (3000), который чувствует себя несколько контр-интуитивным. Я прошел через другие подобные сообщения в Stack Overflow, но было бы неплохо получить представление, специфичное для этого типа общего хранения сообщений.

Tom 07 янв. 2010, в 20:29

Источник

25

Немного стар, но я пришел сюда, потому что столкнулся с проблемой, которая заставила меня задуматься над этим. В моем случае моя форма интерфейса была ограничена 2000 символами, но кодировка, неявная в моем методе хранения, кодировала международные символы в виде нескольких символов (что, очевидно, может составлять от 3 до 12 на символ). Так что мои 2000 внезапно становятся до 24000. Что-то думать о...
James S 24 март 2014, в 22:40
3

Я обнаружил, что текст для многих одновременных вставок значительно быстрее.
Ray S. 28 март 2014, в 08:47
1

@JamesS: utf8mb4 ...>. <
indivisible 20 апр. 2015, в 22:44
4

Я проголосовал, чтобы закрыть это, потому что это устарело. Новые форматы строк были введены позже в 2010 году, аннулировав многие ответы. Такие ответы цитируются Евангелием; было бы лучше избавиться от этой темы, чем оставлять неверную информацию.
Rick James 22 июнь 2018, в 22:07
0

Вот новая тема: dba.stackexchange.com/questions/210408/…
Rick James 22 июнь 2018, в 22:08
0

@ Рик Джеймс - Вопрос, с которым вы связались, совсем не тот же. Обратите внимание, что эту ветку просматривали 400 тыс. Раз, и вы предлагаете заменить ее чем-то с 35 просмотрами и своим собственным ответом в качестве основного ответа? Этот вопрос по-прежнему совершенно актуален и ответы здесь полезны.
Tom 23 июнь 2018, в 20:20
4

@RickJames рассмотрите возможность размещения обновленного ответа, а не закрывайте вопрос
Yvette Colomb♦ 24 июнь 2018, в 02:19
2

@YvetteColomb - я добавил ответ. В основном я хотел бы избавиться от принятого ответа, потому что он устарел . Я пришел в Q & A, потому что кто-то цитировал неверную информацию, говоря: «754 голосов, поэтому это должно быть правильно». ОК, я также отредактировал Утвержденный ответ. (Хотя это кажется неправильным.)
Rick James 25 июнь 2018, в 16:09

Показать ещё 6 комментариев

Теги:

mysql

text

messages

varchar

4 ответа

349

Можете ли вы предсказать, как долго будет вводиться пользователь?

УАКСНАК (Х)

Дело: имя пользователя, адрес электронной почты, страна, тема, пароль

ТЕКСТ

Дело: сообщения, электронные письма, комментарии, форматированный текст, html, код, изображения, ссылки

MEDIUMTEXT

Дело: большие тела json, книги с малой длиной до средней длины, строки csv

LONGTEXT

Дело: учебники, программы, летние файлы журналов, Гарри Поттер и кубок огня, ведение научных исследований

Michael J. Calkins 01 нояб. 2012, в 18:28

7

Предсказуемость действительно побочный элемент здесь. Фактически максимальная ожидаемая длина должна быть решающим фактором. Элементы, которые вы упоминаете как более предсказуемые, только так, потому что они короче, чем другие.
Andrew Barber 01 нояб. 2012, в 19:46
26

@ Andrew-Barber Это моя точка зрения, хотя. Все остальные посты хорошо объясняют различия, но не ситуации, когда вам приходится выбирать между ними. Я пытался указать, что использование varchar для предсказуемо короткого - это хороший выбор, а использование текста для произвольно длинного - хороший выбор.
Michael J. Calkins 01 нояб. 2012, в 20:28
1

Если все столбцы короткие и предсказуемые (например, MAC-адрес, IMEI и т. Д. - это вещи, которые никогда не меняются), то используйте столбцы CHAR, и вы можете установить фиксированный размер строки, что должно значительно ускорить процесс при использовании MyISAM, возможно также InnoDb, хотя я не уверен в этом.
Matt 02 апр. 2013, в 19:15
0

@Matt AWS RDS в основном говорит вам: «Используйте InnoDB, или есть большая вероятность, что ваши резервные копии будут $% # * ed». MySQL почти на той версии, где InnoDB имеет полнотекстовый поиск, а MyISAM будет почти полностью устаревшим.
Michael J. Calkins 14 авг. 2013, в 17:49
1

@ MichaelJ.Calkins То, что произошло в MySQL 5.6. Теперь у вас также есть полнотекстовый поиск в InnoDB. См. Dev.mysql.com/doc/refman/5.6/en/fulltext-search.html.
PhoneixS 05 июнь 2015, в 08:17
0

@PhoneixS не знал, какая версия это сделала! Я взволнован сейчас :)
Michael J. Calkins 05 июнь 2015, в 14:57
7

Пределы символов: TINYTEXT: 255; ТЕКСТ: 65 535; MEDIUMTEXT: 16 777 215; LONGTEXT: 4,294,967,29.
Victor Stoddard 22 фев. 2017, в 01:46
0

@VictorStoddard - это ограничения byte , а не character . См. Также stackoverflow.com/questions/13932750/…
Rick James 25 июнь 2018, в 21:00
0

@Matt - «исправлено» может быть или не быть быстрее в MyISAM. Для InnoDB он ничего не покупает.
Rick James 25 июнь 2018, в 21:02

Показать ещё 7 комментариев

217

Просто для уточнения наилучшей практики:

Сообщения в текстовом формате почти всегда сохраняются как ТЕКСТ (они заканчиваются сколь угодно длинными)
Атрибуты String должны храниться как VARCHAR (имя пользователя-получателя, субъект и т.д.).

Я понимаю, что у вас есть предел переднего конца, и это здорово, пока это не так. * grin * Трюк состоит в том, чтобы думать о БД отдельно от приложений, которые подключаются к нему. Просто потому, что одно приложение ограничивает данные, это не означает, что данные ограничены по существу.

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

James 07 янв. 2010, в 22:35

0

Что значит «что хорошо, пока это не так»? Что означает «не»?
Pacerier 16 июль 2015, в 08:13
6

@Pacerier Чтобы привести пример «не», о котором Джеймс, скорее всего, говорит о: например, Twitter, который до недавнего времени имел ограничение в 140 символов для PM. Они решили, что это больше не имеет смысла, и решили полностью устранить этот предел. Если бы они не думали об этом заранее (что я вполне уверен, что они, вероятно, сделали ...), они бы столкнулись со сценарием, изложенным выше.
PaulSkinner 03 сен. 2015, в 10:42
7

Я просто добавляю нашу новую базу данных, и я предположил, что никто не сможет поместить более 2000 символов в наши крошечные поля для комментариев, а затем, как отмечает Джеймс, сегодня вечером это неожиданно «не в порядке», потому что пользователь прошел через очень правильный комментарий, который был длиной 2600 символов. Я использовал varchar (2000), думая, что это не может продолжаться дольше, и я ошибался. так что да, это здорово, пока это не так. В нашем случае это заняло всего несколько дней. Правило ниже, Майкл Дж. Калкинс, я думаю, что буду использовать с этого момента. текст для сообщений, комментариев.
Lizardx 11 фев. 2016, в 08:17
0

@Pacerier "это здорово, пока не плохо". Другими словами, это работает почти все время и замечательно ... за исключением тех исключительных ситуаций, когда это не так здорово.
Limited Atonement 30 март 2016, в 14:06
0

@Pacerier Еще один интересный пример упоминается в комментариях к выбранному ответу, в основном он имел ограничение внешнего интерфейса в 2000 символов, но введенные символы находились в кодовой странице, которая в действительности использовала больше байтов, чем обычные буквы, его базе данных потребовалось место для 24k символов только потому, что он должен был учитывать фактический размер байта вводимых символов.
RaptorX 01 июль 2016, в 16:45

Показать ещё 3 комментария

29

Отказ от ответственности: я не эксперт по MySQL... но это мое понимание проблем.

Я думаю, что TEXT хранится вне строки mysql, в то время как я думаю, что VARCHAR хранится как часть строки. Для строк mysql существует максимальная длина строки, поэтому вы можете ограничить количество других данных, которые вы можете сохранить в строке, используя VARCHAR.

Также из-за того, что VARCHAR является частью строки, я подозреваю, что запросы, смотрящие на это поле, будут немного быстрее, чем при использовании фрагмента TEXT.

Michael Anderson 07 янв. 2010, в 21:53

37

Ограничение длины строки составляет 65 535 байт [ dev.mysql.com/doc/refman/5.0/en/column-count-limit.html ]. Если ваш столбец имеет кодировку utf8, это означает, что столбец varchar из 3000 символов может занимать до 9000 байт.
Jan Fabry 07 янв. 2010, в 21:05
7

Символы UTF-8 могут иметь длину до 4 байт, поэтому я думаю, что вы имели в виду 12 000 байт (если только в MySQL нет какой-то вещи, которую я не понимаю).
raylu 10 июль 2011, в 03:15
13

@raylu UTF-8 MySQL является «поддельным UTF-8» в том смысле, что он поддерживает максимум 3 байта на символ, поэтому в MySQL UTF-8 нет способа напрямую хранить символы Юникода за плоскостью BMP. Это исправлено в MySQL 5.5.
Pacerier 06 июль 2012, в 05:28
2

Я считаю, что это утверждение действительно только для MyISAM. Я не могу найти точный источник, но я верю, что InnoDB также хранит TEXT в таблице.
dotancohen 02 дек. 2013, в 14:39
2

@dotancohen Я нашел здесь источник, объясняющий, что хранение данных переменной длины с использованием InnoDB может варьироваться (может храниться как внешне, так и внутри строки) mysqlserverteam.com/externally-stored-fields-in-innodb
KiX Ortillan 28 авг. 2015, в 00:43
0

@KiXOrtillan: Хорошо, спасибо!
dotancohen 28 авг. 2015, в 10:14
1

MySQL 5.1 использует 3-байтовый UTF-8. MySQL 5.5 и выше используют 4-байтовый UTF-8 (utf8mb4).
Anthony Rutledge 18 сен. 2015, в 00:11
0

В зависимости от или row_format, размера строки и других вещей, ничего, некоторые или все из TEXT или VARCHAR сохраняются вне записи. Вы не можете сделать простое заявление о том, что делается в InnoDB.
Rick James 25 июнь 2018, в 21:05
0

@AnthonyRutledge - 5.1 не имеет utf8mb4; 5.5-5.7 имеют utf8mb4 в качестве опции ; 8.0 по умолчанию соответствует полному 4-байтовому UTF-8.
Rick James 25 июнь 2018, в 21:07
0

@RickJames Да, но у него есть трехбайтовый UTF-8.
Anthony Rutledge 25 июнь 2018, в 22:36
0

@AnthonyRutledge - Да, utf8 (максимум 3 байта) существует с 4.1.
Rick James 25 июнь 2018, в 23:37
0

@RickJames Позор, однако, о курсорах, представлениях, триггерах и хранимых процедурах.
Anthony Rutledge 26 июнь 2018, в 00:54

Показать ещё 10 комментариев

Ещё вопросы

Немного стар, но я пришел сюда, потому что столкнулся с проблемой, которая заставила меня задуматься над этим. В моем случае моя форма интерфейса была ограничена 2000 символами, но кодировка, неявная в моем методе хранения, кодировала международные символы в виде нескольких символов (что, очевидно, может составлять от 3 до 12 на символ). Так что мои 2000 внезапно становятся до 24000. Что-то думать о...
Я обнаружил, что текст для многих одновременных вставок значительно быстрее.
Я проголосовал, чтобы закрыть это, потому что это устарело. Новые форматы строк были введены позже в 2010 году, аннулировав многие ответы. Такие ответы цитируются Евангелием; было бы лучше избавиться от этой темы, чем оставлять неверную информацию.
Вот новая тема: dba.stackexchange.com/questions/210408/…
@ Рик Джеймс - Вопрос, с которым вы связались, совсем не тот же. Обратите внимание, что эту ветку просматривали 400 тыс. Раз, и вы предлагаете заменить ее чем-то с 35 просмотрами и своим собственным ответом в качестве основного ответа? Этот вопрос по-прежнему совершенно актуален и ответы здесь полезны.
@RickJames рассмотрите возможность размещения обновленного ответа, а не закрывайте вопрос
@YvetteColomb - я добавил ответ. В основном я хотел бы избавиться от принятого ответа, потому что он устарел . Я пришел в Q & A, потому что кто-то цитировал неверную информацию, говоря: «754 голосов, поэтому это должно быть правильно». ОК, я также отредактировал Утвержденный ответ. (Хотя это кажется неправильным.)
Предсказуемость действительно побочный элемент здесь. Фактически максимальная ожидаемая длина должна быть решающим фактором. Элементы, которые вы упоминаете как более предсказуемые, только так, потому что они короче, чем другие.
@ Andrew-Barber Это моя точка зрения, хотя. Все остальные посты хорошо объясняют различия, но не ситуации, когда вам приходится выбирать между ними. Я пытался указать, что использование varchar для предсказуемо короткого - это хороший выбор, а использование текста для произвольно длинного - хороший выбор.
Если все столбцы короткие и предсказуемые (например, MAC-адрес, IMEI и т. Д. - это вещи, которые никогда не меняются), то используйте столбцы CHAR, и вы можете установить фиксированный размер строки, что должно значительно ускорить процесс при использовании MyISAM, возможно также InnoDb, хотя я не уверен в этом.
@Matt AWS RDS в основном говорит вам: «Используйте InnoDB, или есть большая вероятность, что ваши резервные копии будут $% # * ed». MySQL почти на той версии, где InnoDB имеет полнотекстовый поиск, а MyISAM будет почти полностью устаревшим.
@ MichaelJ.Calkins То, что произошло в MySQL 5.6. Теперь у вас также есть полнотекстовый поиск в InnoDB. См. Dev.mysql.com/doc/refman/5.6/en/fulltext-search.html.
@PhoneixS не знал, какая версия это сделала! Я взволнован сейчас :)
Пределы символов: TINYTEXT: 255; ТЕКСТ: 65 535; MEDIUMTEXT: 16 777 215; LONGTEXT: 4,294,967,29.
@VictorStoddard - это ограничения byte , а не character . См. Также stackoverflow.com/questions/13932750/…
@Matt - «исправлено» может быть или не быть быстрее в MyISAM. Для InnoDB он ничего не покупает.
Что значит «что хорошо, пока это не так»? Что означает «не»?
@Pacerier Чтобы привести пример «не», о котором Джеймс, скорее всего, говорит о: например, Twitter, который до недавнего времени имел ограничение в 140 символов для PM. Они решили, что это больше не имеет смысла, и решили полностью устранить этот предел. Если бы они не думали об этом заранее (что я вполне уверен, что они, вероятно, сделали ...), они бы столкнулись со сценарием, изложенным выше.
Я просто добавляю нашу новую базу данных, и я предположил, что никто не сможет поместить более 2000 символов в наши крошечные поля для комментариев, а затем, как отмечает Джеймс, сегодня вечером это неожиданно «не в порядке», потому что пользователь прошел через очень правильный комментарий, который был длиной 2600 символов. Я использовал varchar (2000), думая, что это не может продолжаться дольше, и я ошибался. так что да, это здорово, пока это не так. В нашем случае это заняло всего несколько дней. Правило ниже, Майкл Дж. Калкинс, я думаю, что буду использовать с этого момента. текст для сообщений, комментариев.
@Pacerier "это здорово, пока не плохо". Другими словами, это работает почти все время и замечательно ... за исключением тех исключительных ситуаций, когда это не так здорово.
@Pacerier Еще один интересный пример упоминается в комментариях к выбранному ответу, в основном он имел ограничение внешнего интерфейса в 2000 символов, но введенные символы находились в кодовой странице, которая в действительности использовала больше байтов, чем обычные буквы, его базе данных потребовалось место для 24k символов только потому, что он должен был учитывать фактический размер байта вводимых символов.
Ограничение длины строки составляет 65 535 байт [ dev.mysql.com/doc/refman/5.0/en/column-count-limit.html ]. Если ваш столбец имеет кодировку utf8, это означает, что столбец varchar из 3000 символов может занимать до 9000 байт.
Символы UTF-8 могут иметь длину до 4 байт, поэтому я думаю, что вы имели в виду 12 000 байт (если только в MySQL нет какой-то вещи, которую я не понимаю).
@raylu UTF-8 MySQL является «поддельным UTF-8» в том смысле, что он поддерживает максимум 3 байта на символ, поэтому в MySQL UTF-8 нет способа напрямую хранить символы Юникода за плоскостью BMP. Это исправлено в MySQL 5.5.
Я считаю, что это утверждение действительно только для MyISAM. Я не могу найти точный источник, но я верю, что InnoDB также хранит TEXT в таблице.
@dotancohen Я нашел здесь источник, объясняющий, что хранение данных переменной длины с использованием InnoDB может варьироваться (может храниться как внешне, так и внутри строки) mysqlserverteam.com/externally-stored-fields-in-innodb
MySQL 5.1 использует 3-байтовый UTF-8. MySQL 5.5 и выше используют 4-байтовый UTF-8 (utf8mb4).
В зависимости от или row_format, размера строки и других вещей, ничего, некоторые или все из TEXT или VARCHAR сохраняются вне записи. Вы не можете сделать простое заявление о том, что делается в InnoDB.
@AnthonyRutledge - 5.1 не имеет utf8mb4; 5.5-5.7 имеют utf8mb4 в качестве опции ; 8.0 по умолчанию соответствует полному 4-байтовому UTF-8.
@RickJames Да, но у него есть трехбайтовый UTF-8.
@AnthonyRutledge - Да, utf8 (максимум 3 байта) существует с 4.1.
@RickJames Позор, однако, о курсорах, представлениях, триггерах и хранимых процедурах.

MindStalker · Accepted Answer · 2010-01-07T21-18-00.000Z

760

Лучший ответ

TEXT и BLOB хранятся за столом, при этом таблица имеет указатель на расположение фактического хранилища.

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

MindStalker 07 янв. 2010, в 21:18

143

+1: VARCHAR (хранится в строке) обычно быстрее, если данные часто извлекаются (включается в большинство запросов). Однако для большого объема данных, которые обычно не извлекаются (то есть не ссылаются ни на один запрос), может быть, лучше не хранить данные в строке. Существует верхний предел размера строки для данных, хранящихся в строке.
spencer7593 14 янв. 2011, в 17:54
18

Можете ли вы включить любой источник? Где ты это прочитал? Благодарю.
santiagobasulto 04 окт. 2011, в 19:56
4

@MindStalker Это всегда так 2 года спустя? Я смутно помню, что читал, что ТЕКСТ также может быть встроен, если они маленькие ..?
Øyvind Skaar 16 март 2012, в 13:25
1

@ spencer7593, поэтому, когда мы находимся в пределах 65535 байт на размер строки, мы должны varchar или мы должны text ? В чем именно заключается преимущество хранения данных вне таблиц, когда мы находимся в пределах 65535 байт?
Pacerier 02 июнь 2013, в 03:10
21

@Pacerier: точное преимущество избегания «встроенного» хранения заключается в увеличении количества строк, которые могут быть сохранены в блоке, что означает, что строки таблицы занимают меньше блоков в буферном кеше InnoDB (меньший объем памяти) и означают меньше блоки для переноса на диск и с него (уменьшенный ввод / вывод). Но это только выигрыш в производительности, если на столбцы, хранящиеся вне строки, запросы не ссылаются. Если на большинство столбцов ссылаются на эти столбцы «вне строки», это преимущество в основном испаряется. Встроенный является предпочтительным, если столбцы вписываются в максимальный размер строки и часто ссылаются.
spencer7593 04 июнь 2013, в 22:35
0

@ spencer7593, разве это не InnoDB? Что насчет MyISAM?
Pacerier 06 июнь 2013, в 02:54
1

@Pacerier: я не верю, что это специфично для InnoDB. Я считаю, что это также относится и к MyISAM. Я считаю, что механизм NDB отличается тем, что он хранит первые 255 байтов встроенного столбца TEXT; любые байты за пределами этого хранятся вне строки. pythian.com/blog/text-vs-varchar
spencer7593 06 июнь 2013, в 06:19
0

VARCHAR хранится в строке. Из руководства Mysql dev.mysql.com/doc/refman/5.7/en/storage-requirements.html «Эффективное максимальное количество байтов, которое может храниться в столбце VARCHAR или VARBINARY, зависит от максимального размера строки в 65 535 байтов, который является общим для всех столбцов. "
Gab 26 июль 2013, в 07:52
1

Может ли кто-то предоставить указатели относительно того, где может быть компромисс для общих сценариев оборудования и данных? Я знаю, что должен выполнить тесты для моего конкретного случая, но если я только начинаю и / или у меня нет времени на проведение обширного теста, какие есть разумные точки перегиба для типичных сценариев?
robguinness 22 авг. 2013, в 08:44
212

«VARCHAR быстрее, когда размер разумный». Что такое «разумное» количество символов, 100? 1000? 100000?
tim peterson 22 сен. 2013, в 13:56
115

Этот ответ не является правильным для InnoDB. И VARCHAR, и BLOB / TEXT хранятся в строке с другими столбцами, если значение в данной строке соответствует размеру страницы (16 КБ, и каждая страница должна содержать не менее двух строк). Если строка слишком велика для этого, она переполняется на дополнительные страницы. См. Mysqlperformanceblog.com/2010/02/09/blob-storage-in-innodb для подробного объяснения.
Bill Karwin 01 янв. 2014, в 21:43
0

Однако я согласен с той частью этого ответа, в которой говорится, что вы должны тестировать свои данные, свое оборудование и нагрузку на запрос, потому что это единственный способ убедиться в этом.
Bill Karwin 01 янв. 2014, в 21:47
13

@BillKarwin ... Если я правильно понимаю, то не должно быть никакой разницы в производительности между varchar и blob / text на InnoDB для небольших текстовых элементов? Поэтому было бы разумно просто сделать каждый varchar text типом и позволить БД управлять встроенным или переполнением?
ryvantage 02 янв. 2014, в 23:08
2

Данные для столбца TEXT или BLOB потенциально хранятся в двух отдельных таблицах. Первые 256 байтов TEXT или BLOB будут сохранены в таблице, с которой вы работаете. Любые дополнительные байты хранятся в скрытой таблице. Строки в скрытой таблице имеют длину 2000 байт. http://dev.mysql.com/
Wilson 19 нояб. 2014, в 22:33
2

Если для SELECT требуется создать временную таблицу, она всегда будет создаваться на диске в случае BLOB / TEXT. Это имеет огромное влияние на производительность
akuzminsky 04 июнь 2015, в 23:15
0

Этот ответ не является строго правильным, и очевидно, что 108 человек, которые проголосовали за комментарий Билла Карвина, признавая, что ответ не является правильным, должны были и здесь опустить голос. Нам нужны эти отрицательные голоса, чтобы исправить систему.
Evan Carroll 22 июнь 2018, в 21:08
2

Этот ответ был написан до того, как были представлены Row_format = DYNAMIC и COMPRESSED.
Rick James 22 июнь 2018, в 22:05
0

Иногда правильный ответ меняется со временем. В идеале отрицательные отзывы не должны рассматриваться как критика человека, который дал правильный ответ, а скорее отрицательные и отрицательные, чтобы новый правильный ответ «всплывал», чтобы получить наибольшее количество голосов.
Daryn 16 окт. 2018, в 05:32
0

Однако не каждый может понизить голос, кто может повысить, поэтому всегда будет дисбаланс.
rbassett 12 март 2019, в 22:21

Показать ещё 17 комментариев