pos*_*spi 9 mysql character-encoding sqldatatypes
想知道这两种数据类型将占用多少实际存储空间,因为MySQL文档在这个问题上有点不清楚.
CHAR(M)M×w字节,0 <= M <= 255,其中w是字符集中最大长度字符所需的字节数
VARCHAR(M),VARBINARY(M)L + 1个字节,如果列值需要0 - 255个字节,L + 2个字节,如果值可能需要超过255个字节
这似乎意味着,给定一个utf8编码的数据库,CHAR将始终占用每个字符32位,而VARCHAR将占用8到32之间,具体取决于存储的字符的实际字节长度.那是对的吗？或者VARCHAR是否意味着8位字符宽度,并且存储多个八位字节的UTF8字符实际上会消耗VARCHAR中的多个"字符"？或者VARCHAR是否也始终每个字符存储32位？这么多的可能性.
不是以前我曾经不必担心这件事,但我开始尝试内存临时表大小限制,我不一定要增加MySQL的可用池(第二次).
CHAR并且VARCHAR都计算字符.它们都计算了给定字符编码和长度时可能需要的最大存储空间.对于ASCII,每个字符为1个字节.对于UTF-8,这是每个字符3个字节(不是你所期望的4个字节,因为MySQL的Unicode支持由于某种原因而瘫痪,并且它不支持UTF-8中需要4个字节的任何Unicode字符).到目前为止,CHAR并且VARCHAR是相同的.
现在,CHAR继续前进并保留这一数量的存储空间.
VARCHAR 而是分配1或2个字节,具体取决于此最大存储量是<256还是≥256.并且条目占用的实际空间量是这一个或两个字节,加上字符串实际占用的空间量.
有趣的是,这使得85为UTF-8的神奇数字VARCHAR:
VARCHAR(85) 使用1个字节作为长度,因为最大可能长度为85(残缺的)UTF-8字符是3×85 = 255.VARCHAR(86) 使用2个字节作为长度,因为最大可能长度为86(残缺的)UTF-8字符是3×86 = 258.| 归档时间： |
|
| 查看次数： |
10744 次 |
| 最近记录： |