TINYTEXT，TEXT，MEDIUMTEXT和LONGTEXT最大存储大小
根据MySQL文档 ，有四种文本types：
- TINYTEXT
- 文本
- MEDIUMTEXT
- LONGTEXT
假设字符编码为UTF-8，每个数据types的列中可以存储的最大长度是多less？
从文档 ：
types| 最大长度
----------- + -------------------------------------
TINYTEXT | 255（2 8 -1）个字节
TEXT | 65,535（2 16 -1）个字节= 64个KiB
MEDIUMTEXT | 16,777,215（2 24 -1）字节= 16 MiB
LONGTEXT | 4,294,967,295（2 32 -1）个字节= 4个GiB
请注意，可存储在列中的字符数将取决于字符编码 。
扩大相同的答案
- 这个SOpost： varchar（255）vs tinytext / tinyblob和varchar（65535）vs blob / text概述了开销和存储机制。
- 如第（1）点所述，应始终使用VARCHAR而不是TINYTEXT。 但是，使用VARCHAR时，最大的行数不应超过65535个字节。
- 如http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-utf8.html所述; ，utf-8最多3个字节。
这是一个快速的估计表格！
- 所以最坏的情况下假设（每个UTF-8字符3个字节）到最好的情况（每个UTF-8字符1个字节）
- 假设英语平均每个单词有4.5个字母
- x是分配的字节数
XX
Type | A= worst case (x/3) | B = best case (x) | words estimate (A/4.5) - (B/4.5) -----------+--------------------------------------------------------------------------- TINYTEXT | 85 | 255 | 18 - 56 TEXT | 21845 | 65,535 | 4854.44 - 14,563.33 MEDIUMTEXT | 5,592,415 | 16,777,215 | 1,242,758.8 - 3,728,270 LONGTEXT | 1,431,655,765 | 4,294,967,295 | 318,145,725.5 - 954,437,176.6
请参考Chris V的回答： https ： //stackoverflow.com/a/35785869/1881812
上升到@ Ankan-Zerob的挑战，这是我估计的每个文本types中可以存储的最大字符长度：
Type | Bytes | English words | Multi-byte words -----------+---------------+---------------+----------------- TINYTEXT | 255 | ±44 | ±23 TEXT | 65,535 | ±11,000 | ±5,900 MEDIUMTEXT | 16,777,215 | ±2,800,000 | ±1,500,000 LONGTEXT | 4,294,967,295 | ±740,000,000 | ±380,000,000
在英语中 ，每个单词4.8个字母可能是一个很好的平均值（例如norvig.com/mayzner.html ），但是根据域名（例如口头语言和学术论文），单词长度会有所不同，所以没有太精确的意思。 英文大多是单字节ASCII字符，偶尔有多字节字符，因此接近每字母一字节。 字间空格必须多一个字符，所以我从每个字5.8个字节开始舍去。 有很多口音的语言，比如说波兰语，会存储稍less的单词，比如德语的单词更长。
需要多字节字符的语言，如希腊语，阿拉伯语，希伯来语，印地语，泰语等等，通常需要UTF-8每个字符两个字节。 每个单词5个字母大概猜测，我从每字11个字节往下舍去。
CJK脚本（汉字，汉字，平假名，片假名等）我对此一无所知; 我相信字符大多需要UTF-8中的3个字节，并且（大量简化），可能会考虑使用每个字大约2个字符，所以它们会在另外两个字符之间。 （使用UTF-16的CJK脚本很可能需要更less的存储空间）。
这当然无视存储开销等
“应该总是使用VARCHAR来代替TINYTEXT”。 如果你有很宽的行，Tinytext是有用的 – 因为数据被存储在logging之外。 有一个性能开销，但它确实有用处。
