绝大多数场景应使用b-tree索引，因其支持范围查询、前缀匹配、排序及联合索引最左前缀匹配；hash索引仅适用于memory表的纯等值查询，innodb不支持用户创建。
什么时候该用 B-Tree 索引
绝大多数场景下，B-Tree 是默认且最稳妥的选择。它支持范围查询（比如 WHERE created_at BETWEEN '2023-01-01' AND '2023-12-31'）、前缀匹配（LIKE 'abc%'）、排序（ORDER BY）和多列联合索引的最左前缀生效——这些是业务里天天在写的操作。
常见错误现象：给一个高频 IN 查询的字段建了 Hash 索引，结果发现 ORDER BY 变慢、分页失效、LIKE '%word' 完全走不了索引。
-
B-Tree在 MySQL 中是INDEX或KEY的默认类型，无需显式声明 - 联合索引如
(user_id, status, created_at)，对WHERE user_id = 123 AND status = 'active'有效，但WHERE status = 'active'就无效 - 字符串字段建
B-Tree索引时，如果只查前几位，可考虑加前缀长度（INDEX (email(16))），避免索引过大
什么情况下 Hash 索引才真有用
Hash 索引只适合等值查询（= 或 IN），而且仅限内存表（MEMORY 引擎）或某些特定存储引擎（如 MyISAM 不支持）。InnoDB 根本不支持用户创建 Hash 索引——它的自适应哈希索引（adaptive hash index）是内部机制，不能控制。
使用场景极窄：比如缓存表、临时查重表、固定 ID 映射表，且数据量不大、更新极少、纯等值命中。
- 试图在 InnoDB 表上执行
CREATE INDEX idx ON t (col) USING HASH会报错：ERROR 1064（语法不支持） -
MEMORY表建Hash索引后，WHERE col > 100会直接全表扫描，优化器甚至可能忽略该索引 - 哈希冲突高时（比如大量
NULL或重复值），性能反而比B-Tree差，因为要遍历链表
B-Tree 索引不是建了就快
建了索引不等于查询变快，尤其是当选择性低、数据分布倾斜、或查询条件触发隐式类型转换时，索引可能被完全跳过。
常见错误现象：明明有 INDEX (status)，但 SELECT * FROM orders WHERE status = 'shipped' 还是慢；EXPLAIN 显示 type: ALL，说明没走索引。
- 状态类字段（如
status只有 3–5 个值）选择性差，索引效率低，有时全表扫描更快 -
WHERE status = 1（字段是VARCHAR）会触发隐式转换，导致索引失效 - 索引列参与计算或函数，如
WHERE YEAR(created_at) = 2023，B-Tree无法利用索引做范围定位 - 单列索引和联合索引共存时，优化器可能选错索引，需要用
FORCE INDEX或调整STATS_AUTO_UPDATE
InnoDB 的聚簇索引本质就是 B-Tree
InnoDB 表如果没有定义主键，会自动选一个唯一非空索引作聚簇索引；没有这样的索引，就隐式生成一个 6 字节的 ROW_ID。这意味着：数据行物理存储顺序和主键 B-Tree 的叶子节点完全一致。
这个特性直接影响二级索引的大小和查询路径：每个二级索引叶子节点存的不是数据行指针，而是主键值。所以主键别设太长（比如用 UUID），否则所有二级索引都会跟着膨胀。
- 主键用
BIGINT比CHAR(36)节省空间，二级索引体积可能缩小 3–5 倍 -
SELECT *通过二级索引查，要先查二级索引拿到主键，再回表查聚簇索引——这就是“回表”，开销不小 - 覆盖索引（
SELECT a,b FROM t WHERE a=1，且INDEX (a,b)）能避免回表，但前提是查询字段全在索引里
真正卡住人的，往往不是选 B-Tree 还是 Hash，而是忘了主键设计会影响所有索引的物理结构，以及低估了低选择性字段建索引带来的维护成本和误判风险。
