MySQL 8.0+ 仅 MEMORY 引擎原生支持哈希索引，InnoDB 不支持；对长字符串字段，应使用 MD5() 生成 CHAR(32) 哈希列并建 B+ 树索引，或 MySQL 8.0.13+ 使用 SUBSTRING() 函数索引，辅以双重校验与区分度验证。
直接结论：MySQL 8.0+ 不支持哈希索引（除 MEMORY 引擎外），用 MD5() 或 SUBSTRING() 预处理长字符串字段再建普通 B+ 树索引，是更可行、更稳定的方案。
为什么不能直接在长字符串上建索引
MySQL 的 B+ 树索引对长字段有长度限制：VARCHAR 字段超过 767 字节（或 3072 字节，取决于 innodb_large_prefix 设置）时，建索引会失败或自动截断。即使成功建了前缀索引（如 INDEX idx_long (long_text(100))），JOIN 中的等值匹配仍可能失效——因为优化器无法保证前缀唯一性，常退化为全表扫描。
常见错误现象：
-
EXPLAIN显示type: ALL或key: NULL，即使写了ON t1.long_str = t2.long_str - 执行时间随数据量非线性增长，10 万行就超 2 秒
- 添加前缀索引后
rows扫描数几乎没变
用 MD5() 生成固定长度哈希值并索引
核心思路是把不可索引的长字符串映射为 32 位十六进制字符串（CHAR(32)），再对其建唯一索引。适用于内容稳定、允许极低碰撞概率的场景（如 URL、JSON 文本、日志片段）。
实操建议：
- 新增列存储哈希值：
ALTER TABLE table1 ADD COLUMN long_str_md5 CHAR(32) AS (MD5(long_str)) STORED; - 为该列建索引：
CREATE INDEX idx_long_str_md5 ON table1(long_str_md5); - JOIN 改写为：
ON t1.long_str_md5 = t2.long_str_md5 AND t1.long_str = t2.long_str（双重校验防碰撞） - 注意：如果原始字段会更新，
STORED列自动同步；若用VIRTUAL则 JOIN 时无法走索引
用 SUBSTRING() 截取高区分度前缀
比哈希更轻量，适合前 N 个字符已具备足够区分度的场景（如邮箱域名、路径前缀、协议头）。不引入额外列，改造成本最低。
实操建议：
- 先验证前缀区分度：
SELECT COUNT(DISTINCT SUBSTRING(long_str, 1, 16)) / COUNT(*) FROM table1;—— 值接近 1 才值得用 - 建前缀索引：
CREATE INDEX idx_long_str_16 ON table1(SUBSTRING(long_str, 1, 16));（MySQL 8.0.13+ 支持函数索引） - JOIN 条件必须显式使用相同截取逻辑：
ON SUBSTRING(t1.long_str, 1, 16) = SUBSTRING(t2.long_str, 1, 16) - ⚠️ 不能混用
SUBSTRING(long_str, 1, 16)和long_str，否则索引失效
容易被忽略的关键点
无论选 MD5 还是 SUBSTRING，真正卡住性能的往往不是索引本身，而是 JOIN 后的回表或临时表膨胀：
- 如果 SELECT 列包含未覆盖的长文本字段（如
TEXT），即使索引生效，每行仍要回原表读取，IO 成倍增加 - JOIN 多张大表时，中间结果集可能超出
tmp_table_size，触发磁盘临时表，速度骤降 - 隐式类型转换会让所有努力白费：比如一边是
utf8mb4_bin，另一边是utf8mb4_general_ci，索引直接失效
