绝大多数情况下应默认使用btree索引，因其支持范围查询、排序、最左前缀匹配且稳定通用；hash仅适用于memory引擎的等值查询，受限多、易退化、不可控。
什么时候该用 BTREE 索引而不是 HASH
绝大多数情况下，你应该默认选 BTREE（mysql 实际上就是 B+Tree）。它不是“更老”的选择，而是更稳、更通用的选择。
-
HASH只支持=和IN等精确匹配，一遇到WHERE age > 25、ORDER BY created_at、LIKE 'abc%'就完全失效 - InnoDB 存储引擎根本不允许你手动创建
HASH索引——它只在内部启用「自适应哈希索引」（AHI），且完全由引擎自动判断是否构建，你无法控制 -
MEMORY引擎才真正支持用户定义的HASH索引，但这类表只存临时数据，重启即丢，不适合主业务表 - 联合索引中，
HASH必须完整匹配所有字段（比如索引是(a,b,c)，查询条件必须同时带a=1 AND b=2 AND c=3），而BTREE支持最左前缀，a=1或a=1 AND b=2都能命中
HASH 看似快，为什么实际容易翻车
单次等值查询时，HASH 理论上一次函数计算就能定位槽位，比 BTREE 的树遍历更快。但这个“快”非常脆弱。
- 一旦发生哈希碰撞（比如大量
status = 'pending'的记录），多个键映射到同一个槽位，就得退化成链表遍历——性能可能比全表扫描还差 - 哈希值不保留原始顺序，所以
select ... ORDER BY id无法利用HASH索引避免排序；GROUP BY同理 - 没有叶子节点指针链，没法做范围扫描或翻页（
LIMIT 1000,20这种偏移量分页会反复回表） - 内存占用不可控：哈希表需要预留空槽位防碰撞，空间利用率远低于紧凑存储的
B+Tree叶子节点
InnoDB 中的「自适应哈希索引」到底靠不靠谱
它不是你建的索引，而是 InnoDB 在运行时，对某些高频访问的 BTREE 叶子页自动缓存的哈希映射，用来加速重复的等值查询。
- 仅适用于访问模式高度重复的场景（比如反复查
user_id = 12345），且对应 B+Tree 节点已常驻缓冲池 - 它不替代
BTREE，只是锦上添花；如果BTREE设计不合理（比如没覆盖查询字段），AHI 也救不了 - 无法通过 SQL 控制开启/关闭，也不能指定字段；可通过
innodb_adaptive_hash_index配置项全局开关（MySQL 8.0+ 默认 ON） - 高并发写入下，AHI 维护本身会成为锁争用点，有时反而要关掉来保稳定性
建索引时怎么避免掉进 HASH 幻觉
看到“哈希快”就想去用 HASH，是典型被术语误导。真实瓶颈往往不在单次查找速度，而在查询模式和数据分布。
- 别被
EXPLAIN里偶尔出现的using index condition或Using where; Using index欺骗——这跟哈希无关，是BTREE的索引下推或覆盖优化 - 测试
HASH前，先确认你的引擎是否真支持（SHOW CREATE table t看引擎类型；SELECT ENGINE FROM information_schema.TABLES） - 即使用了
MEMORY表，也要压测碰撞率：用SELECT count(*), COUNT(DISTINCT hash_value) FROM ...估算冲突程度 - 真正影响响应时间的，往往是磁盘 IO 和回表次数——
B+Tree的有序性和聚簇特性，在大多数 OLTP 场景中比哈希的理论优势更实在
哈希索引不是“高级选项”，而是窄口径特化工具。多数人真正需要的，是一棵结构清晰、行为可预测、能撑住各种查询变化的 B+Tree。