不能直接给 varchar(6000) 加 B-Tree 索引，因 InnoDB 有前缀长度限制（767/3072 字节），且长字符串导致页分裂频繁、缓存差、比较慢，等值查询性能未必优于全表扫描。
为什么不能直接给 varchar(6000) 加 B-Tree 索引
MySQL 的 B-Tree 索引对长字符串支持差，不只是因为索引体积大——InnoDB 默认单列索引前缀限制是 767 字节（utf8mb3）或 3072 字节（utf8mb4），但即便能建成功，索引页分裂频繁、缓存效率低、比较开销高，实际查询仍慢。更关键的是，WHERE src_text = 'xxx' 这类等值查询，在区分度高但长度爆炸的字段上，B-Tree 并不比全表扫描快多少。
CRC32 列必须用 bigint 而不是 int
MySQL 的 CRC32() 返回值范围是 0–4294967295，刚好超过 unsigned int 的最大值（4294967295 是上限，但 int(10) 无符号也仅到 4294967295，看似够？错——InnoDB 存储引擎对整型索引列有对齐和隐式转换风险，且部分 MySQL 版本在计算时可能产生负值（虽文档说无符号，但某些客户端或连接层会误判）。实测中用 int 容易触发截断或隐式类型转换，导致索引失效。
- 建表时必须声明为
bigint UNSIGNED或至少bigint - 插入/更新时若手动计算，务必用
CRC32('str') & 0xFFFFFFFF确保非负（MySQL 8.0+ 更稳定，但兼容旧版本建议加掩码） - 不要依赖 PHP 或应用层算 CRC32 后写入：PHP 的
crc32()返回有符号整数，和 MySQL 结果不一致
查询时必须同时带哈希值和原字符串
单独查 WHERE src_text_crc = 1234567890 是危险的——CRC32 碰撞概率在 9.3 万行时就达 1%，百万级表里重复哈希值很常见。优化器可能走索引拿到几十行，再逐行比对 src_text，性能反而不如加了前缀索引的 B-Tree。
- 正确写法永远是：
WHERE src_text_crc = CRC32('xxx') AND src_text = 'xxx' - 把
CRC32()放在 WHERE 右侧，避免函数作用于列（否则索引失效） - 如果业务允许模糊匹配（如 LIKE 'xxx%'），哈希索引完全无用，别硬套
- ORDER BY 或 GROUP BY 无法利用
src_text_crc排序，它和原字符串顺序无关
自动维护哈希列要用触发器，别靠应用逻辑
靠应用层每次 INSERT/UPDATE 时手动算 CRC32 并赋值，极易漏掉、出错或不一致。MySQL 原生支持 BEFORE INSERT / BEFORE UPDATE 触发器，可靠性高且无网络延迟。
- 触发器内直接调用
CRC32(NEW.src_text)，无需转义或额外处理 - 注意 NULL 值：若
src_text可为空，CRC32(NULL)返回NULL，会导致索引列为空，影响等值查询效果；建议设默认值或加判断 - 避免在触发器里调用 MD5/SHA1：它们返回字符串，索引体积大、比较慢，违背哈希索引初衷
真正难的不是加一列或写个触发器，而是想清楚：你的查询模式是否真的只做等值判断？有没有分页、排序、LIKE、全文检索需求？一旦有，哈希索引就得退场——它只是窄场景下的精准手术刀，不是万能膏药。
