6

我正在阅读 MySQL 5.6 只能索引a （或其他基于文本的类型）的前 767 个字节。varchar我的模式字符集是utf-8，因此每个字符最多可以存储 3 个字节。由于 767/3 = 255.66，这表明需要以 255 个字符编制索引的文本列的最大长度。经验似乎证实了这一点，如下所示：

create table gaga (
    val varchar(255),
    index(val)
)   engine = InnoDB;

但是更改 to 的定义val会varchar(256)产生“错误代码：1071。指定的密钥太长；最大密钥长度为 767 字节”。

在当今时代，255 个字符的限制似乎非常低，所以：这是正确的吗？如果这是用 MySQL 索引更大的文本的最佳方法是什么？（我应该避免它吗？存储一个 SHA？使用另一种索引？使用另一种数据库字符编码？）

4

1 回答 1

7

Though the limitation might seem ridiculous, it makes you think over if you really need the index for such a long varchar field. Even with 767 bytes the index size grows very fast and for a large table (where it is most useful) most probably won't fit into memory.

From the other side, the only frequent case at least in my experience where I needed to index a long varchar field was a unique constraint. And in all those cases a composite index of some group id and MD5 from the varchar field was sufficient. The only problem is to mimick the case-insensitive collation (which considers accented charactes and not-accented equal), though in all my cases I anyway used binary collation, so it was not a problem.

UPD. Another frequent case for indexing a long varchar is ordering. For this case I usually define a separate indexed sorter field which is a prefix of 5-15 characters depending on data distribution. For me, a compact index is more preferable than rarely inaccurate ordering.

于 2013-04-30T19:47:49.347 回答