我有一些数据要存储在MySQL中。数据保证少于1024个字符，但不保证少于255个字符。有两种解决方案。（1）使用text列存储文本（2）使用4个varchar列存储文本，分为4个部分这两种方案的优缺点是什么？我知道文本列会有额外的磁盘读取时间。但阅读4列，我不确定它是否比磁盘读取快。我也不确定实际存储大小的平均比较。
jum4pzuy1#
VARCHAR列最多可以包含65 535个字符.如果字符集为utfmb4，则TEXT或VARCHAR列最多可索引767个字符.如果字符集为latin1，则最多可索引3072个字符.如果我是您，我会使用单个VARCHAR（1023）列。
4uqofj5v2#
MySQL的InnoDB存储引擎将以相同的方式存储所有列，如果可能的话，尝试将它们放在同一个数据页面上，如果必要的话，溢出到额外的页面。不管你是把你描述的长度的字符串存储在一列还是多列中，它们很可能都存储在同一个数据页上，所以无论用哪种方式存储字符串，都不会有额外的页被读取。我认为你在描述一种微优化的尝试，它不会有什么不同。它只会使你的查询复杂化，因为你必须重新连接列。
cig3rfwq3#
KISS --一列。至于TEXT和VARCHAR(1024)，可能没有足够的区别需要担心，它们的处理几乎是相同的，除了可索引性。文本列将有额外的磁盘读取时间这是错误的。列是否存储为“非记录”并不取决于此。你会有数百万行吗？如果不是，不要担心磁盘空间。如果你确实需要担心磁盘空间，我们可以讨论压缩该列。（它是“文本”吗？）
TEXT
VARCHAR(1024)
3条答案
按热度按时间jum4pzuy1#
VARCHAR列最多可以包含65 535个字符.
如果字符集为utfmb4，则TEXT或VARCHAR列最多可索引767个字符.如果字符集为latin1，则最多可索引3072个字符.
如果我是您，我会使用单个VARCHAR（1023）列。
4uqofj5v2#
MySQL的InnoDB存储引擎将以相同的方式存储所有列，如果可能的话，尝试将它们放在同一个数据页面上，如果必要的话，溢出到额外的页面。
不管你是把你描述的长度的字符串存储在一列还是多列中，它们很可能都存储在同一个数据页上，所以无论用哪种方式存储字符串，都不会有额外的页被读取。
我认为你在描述一种微优化的尝试，它不会有什么不同。它只会使你的查询复杂化，因为你必须重新连接列。
cig3rfwq3#
KISS --一列。
至于
TEXT和VARCHAR(1024)，可能没有足够的区别需要担心，它们的处理几乎是相同的，除了可索引性。文本列将有额外的磁盘读取时间
这是错误的。列是否存储为“非记录”并不取决于此。
你会有数百万行吗？如果不是，不要担心磁盘空间。如果你确实需要担心磁盘空间，我们可以讨论压缩该列。（它是“文本”吗？）