哪个更有效：文本 (765) 或 varchar (765) 来存储自由格式的可搜索描述？

Question

编辑：转述问题 - 我在什么时候从 varchar 切换到 text 并返回？

关于这个问题的一点背景。假设我们有 sales_orders 表，我们希望能够在订单上保留一个带有客户或销售代表评论的注释字段。它需要是可搜索的LIKE "%goldfinger's gun%"我们知道我们不会在字段中存储“战争与和平”，但同时它应该足够大以处理一两句话。

那么哪个选项是：

• 读取速度更快？
• 更擅长存储数据？
• 更适合全文搜索？
• 索引？

假设 MySQL(InnoDB) 或 PostgreSQL 用例

Answer 1

就Postgres而言，性能上没有区别。并且没有长度修饰符 fortext开始，只是（可选） for varchar。

除非您需要强制执行特定长度，否则只需使用textor varchar。

• 当所有值都是 36 个字符时，使用 char 和 varchar 进行索引查找会明显更快吗

为了支持与 的模式匹配LIKE，我建议使用三元索引。细节：

• 如何创建索引以加速对表达式的聚合 LIKE 查询？

还有基于字典的全文搜索，它有自己的一组运算符。以下是 Postgres 中模式匹配选项的概述：

• PostgreSQL 中 LIKE、SIMILAR TO 或正则表达式的模式匹配

Answer 2

总结： VARCHAR 和 TEXT 在读取、存储、FULLTEXT 和几乎所有其他方面都是相同的。下面指出了一些 INDEX/SELECT 差异。

MariaDB 和 MySQL（我很确定）在这方面彼此相同。

765的一些原因？您使用的是什么字符集？（Ascii 与 utf8 - 可能存在差异。）

对于“小”VARCHAR（最多 512 个？），与 TEXT 相比有一个小优势：当查询需要创建 tmp 表时，小 VARCHAR 可以使用 MEMORY 来完成。TEXT 为 tmp 表强制使用 MyISAM。这可能会影响某些查询的速度（MEMORY 更快）。

TEXT 不能有普通的 INDEX；小的 VARCHAR 可以。（我不确定 765；尝试 CREATE TABLE；如果它太大，它会向你吐口水。）

您可以使用“前缀”索引，例如INDEX (foo(55))，但它对您的LIKEs 没用，而且通常对任何其他目的也没用。

UUID 应该打包到 BINARY(16) 中，类似于 Postgres 中提到的内容。16 更小，因此效率更高。

LIKE '%foo%' 对 VARCHAR 和 TEXT 的作用相同。相同的速度、相同的语法等。前导通配符使得无法使用 INDEX，从而禁止任何索引优化。

FULLTEXT 索引适用于 VARCHAR 和 TEXT，在 MyISAM 和（从 ~5.6.4 开始）在 InnoDB 中。但是 FULLTEXT 是面向文字的，并且有一些注意事项。此外，MyISAM 和 InnoDB 之间的警告是不同的。