MySQL max key length is 3072 bytes 伤心

[nnegier]

报的错：
ERROR 1071 (42000): Specified key was too long; max key length is 3072 bytes

但我确实需要大一点的 key ，因为这里有个 key 是文件路径 filepath(varchar)，怕有些路径逆天的长，所以才希望越大越好

unique index xr_top_index(filepath,account)

但是系统不允许，感觉这样的话只好作罢？

[xenme]

别放索引就好了，如果要按照文件路径来搜索，当文本来搜索，如果都是精确匹配是不是可以再存一个 hash 值作为索引

[zed1018]

要不考虑做个 hash 再用 key ？然后查询的时候用 hash ？

[dlmy]

弄个冗余字段，存 filepath 的 hash 值

[jorneyr]

楼上的方案挺好，精确匹配就用 Hash ，部分匹配的话对 filepath 列增加全文索引。

示例： 假设我们有一个表 articles ，其中包含 title 和 content 列，我们想要在这些列上创建全文索引。
CREATE FULLTEXT INDEX idx_fulltext ON articles(title, content);

[rockyliang]

可以考虑仅取 filepath 前面一部分的内容做索引，例如`ADD INDEX xr_top_index(filepath(200), account)`就是仅索引 filepath 前面 200 个字符

[Seulgi]

说哈希的，你们没注意到人家是 unique 吗

[adoal]

一定要用 MySQL 吗

[zed1018]

@Seulgi sha512 的碰撞概率已经极低了，要不然您觉得怎么办比较好。

[Seulgi]

@zed1018 #8 不管你概率低不低，只要是 hash ，碰撞上了就是一个 bug ，他现在这个 path 是否能拆分，具体场景都没说清楚，给不了什么好办法。如果只是针对文件名，那么说明 path 对于索引来讲是无效的，然后考虑文件名是否有重复的可能，可以直接用文件名做索引。如果整个场景就是文件服务器，需要根据 path 去匹配某个文件夹下的所有文件夹和文件，可以考虑换数据库。

[ftsland]

可以加个缩写字段作为索引, 跟日志一样 , 把完整的路径调整为路径的首字母 /dir/www/something/file_123 -> /d/w/s/file_123

[qping]

@ftsland 和 hash 本质上没有区别，都是对路径进行了摘要

[tomwei7]

可以尝试把 character 改成 binary 这样 filepath 可以设置到 varchar(3000) 左右，如果 character 是 utf8mb4 filepath 只能到 varchar(700) 左右

[june4]

@Seulgi 你竟然还在担心 hash 碰撞？不如担心流星把人类毁灭了可能性大一些

[zed1018]

@Seulgi #9 有限的预算，有限的需求做有限的方案，这是很正常的事情。绝大多数项目都是遇到了再说，最多再多冗余考虑一两步。人家上来提了这么一个问题，我们给了一个认为成本代价比较低的方案，您说了半天也没见给了什么有意义的东西（除了批判）。哪怕您在我们 hash 的方案基础上提是不是 hash key 不做 unique ，select 到多个结果以后在 coding 层面去对 path 做 equals ，那也是一种。

[wellerman]

@Seulgi 这个很好解决，rehash 呗。既然要精确，那插入时判断一下，hash 存在，路径不相等就 rehash 。

[Seulgi]

@zed1018 #14 不知道哥们在急啥，我就说了一句没有注意到人家的 unique 吗，就我在批判了？我提出一个 hash 碰撞问题，就是在否认你们方案了？那可能你们在头脑风暴的时候只适合别人奉承你了。我没有随意给出方案的原因前面回复你了，因为题主场景并不详细，需要补充。针对两种详细的场景也给了方案。如果别人不认同，就是在批判你，那我觉得我们不适合讨论。直接 ban 就好了。

[laqow]

默认 256 字符路径长度的 windows 惊了

[RobinzzZ]

这问题我们也遇到过，直接改成不让用户建立层级那么深的目录了， 一般也用不着

[Rickkkkkkk]

不允许呗.

[lisxour]

谁家好人的路径，3kb 都不够放啊