在 MySQL中何时使用text
类型而不是大型类型是否有/有任何比较、个人经验或指南?varchar
虽然我的数据库中的大多数条目将少于 1000 个字符,但有些可能会占用 4000 个或更多字符。varchar
什么是text
更好的变体的限制长度?
我不需要索引这些字段。
我没有亲身经历,但这个人有:
快速回答:varchar 快了一点。
编辑-不,不是。他对它们进行了不同的索引——他在 varchar 上有一个完整的索引(255 个字符),但在文本上有一个 255 个字符的前缀索引。当他删除它时,他们的表现或多或少相同。
在线程的后面是这个有趣的花絮:
当 SELECT 需要 tmp 表时,第一个选择是使用 MEMORY,这将是 RAM-only,因此可能会明显更快。(第二个选择是MyISAM。)但是,TEXT 和BLOB 在MEMORY 中是不允许的,所以它不能使用它。(还有其他原因可能会跳过 MEMORY。)
编辑 2 - 一些更相关的信息,这次比较不同索引处理各种类型的方式。
MyISAM 将 TEXT 和 BLOB 置于“内联”。如果您正在搜索一个表(范围扫描/表扫描),那么您就是在“踩过那些牛田”——磁盘 I/O 成本很高。也就是说,在这种情况下,内联 blob 的存在会损害性能。
InnoDB 仅将 767 个字节的 TEXT 或 BLOB 内联,其余的放入其他块。这是一种有时会有所帮助,有时会损害性能的折衷方案。
其他东西(Maria?Falcon?InnoDB 插件?)将 TEXT 和 BLOB 完全放在别处。与 VARCHAR 相比,这将在性能上产生显着差异。有时 TEXT 会更快(例如,不需要 blob 的范围扫描);有时 VARCHAR 会更快(例如,如果您需要查看和/或返回它)。
当然,最好的了解方法是自己使用真实数据集或至少模拟的等效数据集进行一些测试。只需编写一些脚本来填充数据并运行您的选择。使用不同大小的 varchar 进行测试,然后是文本,并测量时间和整体系统利用率(cpu/负载、内存、磁盘 i/o)。
如果您将有足够的负载,这很重要,那么无论如何您都应该进行自动化测试。