TINYTEXT,TEXT,MEDIUMTEXT和LONGTEXT最大存储容量

Lal*_*h B 744 mysql innodb

根据MySQL文档,有四种TEXT类型:

  1. TINYTEXT
  2. 文本
  3. MEDIUMTEXT
  4. LONGTEXT

假设字符编码为UTF-8,我可以在每种数据类型的列中存储的最大长度是多少?

Bri*_*dge 1454

文档:

      Type | Maximum length
-----------+-------------------------------------
  TINYTEXT |           255 (2 8−1) bytes
      TEXT |        65,535 (216−1) bytes = 64 KiB
MEDIUMTEXT |    16,777,215 (224−1) bytes = 16 MiB
  LONGTEXT | 4,294,967,295 (232−1) bytes =  4 GiB

需要注意的是数目可以存储在您的专栏将取决于字符编码.

  • 为什么在docs中比在stackoverflow中更难找到它 (14认同)
  • @Lykos是的,很好 - 取决于角色.从文档中:`一个TEXT列,最大长度为255(28 - 1)个字符.如果值包含多字节字符,则有效最大长度会减少.有关更多详细信息,请参阅Ankan的答案. (8认同)
  • @ aurel.g这就是你真正回答问题的方法.我同意Christophe,这就是mySQL应该如何呈现它的参数 - 即使它只是作为他们......神秘文本视图的补充速记. (4认同)
  • @Bridge不确定我理解,但这意味着TINYTEXT最多可以达到255个字符,我是对的??? (3认同)
  • @GaborSch 所以你是说文档是错误的?恐怕我刚刚编写了一个测试,将 65535 个字符插入到 TEXT 列中,没有问题。 (2认同)
  • @BorisD.Teoharov 这似乎是 MySQL 命名其文档页面的方式,如果不指定确切的所需单词,则很难找到。新文档在这里 https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html (2认同)

Ank*_*rob 235

扩展相同的答案

  1. 这个SO帖子: varchar(255)vs tinytext/tinyblob和varchar(65535)vs blob/text 详细列出了开销和存储机制.
  2. 如第(1)点所述,应始终使用A VARCHAR而不是TINYTEXT.但是,使用VARCHAR时,max rowsize不应超过65535个字节.
  3. http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-utf8.html所述,utf-8最多3个字节.

这是一个用于快速决策的粗略估计表!

  1. 所以最坏的情况假设(每个utf-8字符3个字节)到最佳情况(每个utf-8字符1个字节)
  2. 假设英语每个单词平均有4.5个字母
  3. 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 |          21,845     | 65,535            | 4,854.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
Run Code Online (Sandbox Code Playgroud)

请参阅Chris V的答案:https://stackoverflow.com/a/35785869/1881812

  • @vlasits阅读包含的SO帖子了解详情.(1)所有文本类型(包括tinytext)都存储为行外的对象,这是一个开销(2)然后这些对象由地址8或16字节引用.所以无论你的微小文本多么微小,你都会增加不必要的开销,最大大小为255字节.很明显应该使用varchar,它不会有任何上述开销. (24认同)
  • 这个"A VARCHAR应该总是用来代替TINYTEXT"的理由是什么?有时使用较小的TINYTEXT会不会更好(因为存储效率更高)? (4认同)
  • @ Ankan-Zerob鉴于很明显TINYTEXT永远不能用于VARCHAR,即使将它作为一种选择,理由是什么?是否有必要进行一些模糊的用例? (4认同)
  • @nextgentech查看https://dev.mysql.com/doc/refman/5.0/en/column-count-limit.html.记录大小限制为64 KiB.一张表限于4k列.对于记录大小,`TINYTEXT`计数1字节+ 8字节,而对于记录大小,`VARCHAR(255)`从1字节+ 255字节到2字节+ 1020字节(4字节UTF-8字符)计数. (2认同)
  • 我喜欢用单词表示字段大小,但是...英语通常被认为每个单词大约有5个字符,并且还有一个空格字符要存储; 但是,英语将始终接近每个UTF-8字符1个字节,因此我将除以6给出大约40/10,000/2,700,000/710,000,000个单词的不同大小.有很多口音的语言,比如波兰语的单词会少一些; 希腊语,希伯来语,阿拉伯语等(大多数是2字节序列)大约一半; CJK表意文字是3或4字节序列,但我不知道单词有多长. (2认同)

Chr*_*isV 41

上升到@俺看-Zerob的挑战,这是我可以存储在每个文本类型的最大长度的估计在测量的话:

      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
Run Code Online (Sandbox Code Playgroud)

英语中,每个单词4.8个字母可能是一个很好的平均值(例如norvig.com/mayzner.html),尽管单词长度会根据域名(例如口语与学术论文)而有所不同,因此没有必要过于精确.英语主要是单字节ASCII字符,偶尔有多字节字符,因此接近每字节一个字节.字间空间必须有一个额外的字符,所以我从每个字的5.8个字节向下舍入.有很多口音的语言,例如说波兰语,会存储稍微少一些的单词,例如德语,单词较长.

需要多字节字符的语言,如希腊语,阿拉伯语,希伯来语,印地语,泰语等,通常需要UTF-8中每个字符两个字节.每个单词5个字母疯狂地猜测,我从每个单词的11个字节向下舍入.

CJK剧本(汉字,汉字,平假名,片假名等)我一无所知; 我相信字符大多需要UTF-8中的3个字节,并且(大量简化)它们可能被认为每个字使用大约2个字符,因此它们将介于其他两个字符之间.(CJK脚本可能需要使用UTF-16来减少存储,具体取决于).

这当然忽略了存储开销等.


col*_*117 6

很好,但是不能回答问题:

“应该始终使用VARCHAR代替TINYTEXT。” 如果行很宽,则Tinytext很有用-因为数据存储在记录之外。有性能开销,但确实有用。