MySQL除MEMORY引擎外不支持显式哈希索引，InnoDB仅支持BTREE；其自适应哈希索引为自动、不可控、不持久机制；需手动添加哈希列（如CRC32）并建BTREE索引，查询时须同时使用哈希条件与原字段校验。
MySQL 为什么不能直接建哈希索引（除 MEMORY 引擎外）
MySQL 的 InnoDB 存储引擎不支持显式创建 HASH 索引，这是很多人踩坑的起点。你执行 CREATE INDEX idx ON t (col) USING HASH 会报错 ERROR 1064 —— 因为 InnoDB 只接受 BTREE，USING HASH 仅对 MEMORY 表有效。
InnoDB 内部确实用哈希加速了 adaptive hash index（自适应哈希索引），但它完全自动、不可控、不持久，且只对等值查询 + 高频访问的 B+ 树页生效，没法按需设计。
所以真要“利用哈希索引思想”，得靠自己模拟：在表里加一列存哈希值，再给它建 BTREE 索引——本质是把哈希计算从查询时移到写入时，换空间和写开销，换查询速度。
如何安全添加自定义哈希列并建立高效索引
核心是选对哈希函数、控制长度、避免冲突，并让优化器愿意用上这个列。别直接用 MD5(col) 或 SHA2(col, 256)，它们太长、太慢、还浪费索引空间。
-
UNHEX(MD5(col))转成二进制后取前 8 字节，再转BINARY(8)，比全量 MD5 节省 75% 索引体积 - 更轻量推荐
CRC32(col)，返回 4 字节无符号整数，INT UNSIGNED类型即可存下，索引极小且比较快 - 必须加
NOT NULL和DEFAULT 0，避免 NULL 值干扰等值匹配和索引选择率 - 建索引时用
INDEX idx_hash_col (hash_col)，别加冗余字段——哈希列本身就要承担等值过滤主责
示例：
ALTER TABLE users ADD COLUMN email_hash INT UNSIGNED NOT NULL DEFAULT 0; UPDATE users SET email_hash = CRC32(email); ALTER TABLE users ADD INDEX idx_email_hash (email_hash);
查询时怎么写才能命中自定义哈希索引
光有索引没用，SQL 得跟哈希列严格对齐。优化器不会自动把 WHERE email = 'a@b.c' 重写成 WHERE email_hash = CRC32('a@b.c') —— 它压根不知道你这列是哈希来的。
所以查询必须显式带上哈希条件，且哈希计算逻辑必须和建列时完全一致（包括类型转换、NULL 处理）：
- 写法必须是：
WHERE email_hash = CRC32(?) AND email = ?—— 前者走索引快速定位，后者做精确校验防哈希碰撞 - 千万别只写
WHERE email_hash = CRC32(?)，CRC32 碰撞概率虽低（约 1/40 亿），但在百万级数据里已不可忽视 - 参数顺序不能反：先算哈希过滤，再用原字段确认，否则可能全表扫
email - 如果用的是
BINARY类型哈希列，注意客户端传参是否带隐式字符集转换，建议统一用utf8mb4_bin排序规则
哪些场景适合、哪些千万别用
自定义哈希列不是银弹。它只在明确满足「高频等值查询 + 原字段过长或类型不适合索引」时才值得引入。
- 适合：
VARCHAR(255)存邮箱/URL/JSON ID，查WHERE url = 'https://...'；或TEXT字段前缀太短导致区分度差 - 不适合：
WHERE name LIKE 'zhang%'这类范围/前缀查询——哈希值完全打乱原始顺序，B+ 树索引失效 - 不适合：频繁更新哈希源字段的表——每次
UPDATE都要重算哈希列，额外 I/O 和锁开销明显 - 注意兼容性：
CRC32()在 MySQL 8.0.23+ 支持非字符串入参（如CRC32(123)），但旧版本只认字符串，务必测试
真正容易被忽略的点是：哈希列和原字段的数据一致性。没有数据库级约束能保证二者同步，应用层每次写入都必须同时更新两者，漏一次就查不到——这不是索引问题，是数据完整性问题。
