MySQL不走索引主因是优化器估算选择性低（超20%～30%行数时宁选全表扫描），叠加左模糊、函数操作、隐式转换、联合索引未用最左前缀等导致索引失效；回表因二级索引只存索引列+主键，查非索引列需回聚簇索引取数据。
MySQL 为什么有时不走索引，即使字段上有索引
不是有索引就一定用。MySQL 优化器会估算 WHERE 条件的「选择性」（selectivity）：如果预估要扫描的行数超过全表的约 20%～30%，它大概率放弃索引、直接走全表扫描。这比反复回表更便宜。
常见诱因包括：
-
LIKE '%abc'—— 左模糊导致索引失效（B+Tree 无法从中间开始定位） - 对索引列做函数操作，如
WHERE YEAR(create_time) = 2023，create_time索引无法被直接使用 - 隐式类型转换，比如
user_id是INT，但写成WHERE user_id = '123'，MySQL 可能放弃索引 - 联合索引未满足最左前缀，例如索引是
(a, b, c)，但查询只用了WHERE b = 2 AND c = 3
什么是回表？为什么 SELECT * 容易触发回表
InnoDB 的二级索引（非聚簇索引）叶子节点只存「索引列值 + 主键值」，不存整行数据。当查询需要的列不在该索引中时，MySQL 必须拿着主键再去聚簇索引（即主键索引）里查一次——这个过程叫「回表」。
例如：
CREATE INDEX idx_name ON users(name); SELECT * FROM users WHERE name = 'Alice';
这里 idx_name 能快速定位到主键，但 SELECT * 需要所有字段，就必须回表查聚簇索引。而如果只查 SELECT name, id，且 id 是主键，那 idx_name 叶子节点已有全部所需数据，就不回表（称为「覆盖索引」）。
关键点：
- 回表本质是「随机 IO」，性能代价远高于顺序扫描索引树
- 联合索引设计时，把
WHERE条件列放前面，把SELECT中高频用到的列尽量包含在后边，可减少回表 -
EXPLAIN结果中Extra列出现Using index condition表示用了索引下推（ICP），Using where; Using index表示覆盖索引，没有回表
FORCE INDEX 能绕过优化器选错索引的问题吗
能，但只是临时止血，不能替代索引设计和统计信息更新。
当优化器误判、本该走索引却走了全表扫描时，可用 FORCE INDEX 强制指定：
SELECT * FROM orders FORCE INDEX (idx_status_created) WHERE status = 'paid' AND created_at > '2024-01-01';
但要注意：
- 如果强制的索引根本无法过滤
WHERE条件（比如索引列完全不匹配），语句会直接报错ERROR 1176 (HY000): Key 'xxx' doesn't exist in table 'yyy' -
FORCE INDEX不影响执行计划中是否回表，只控制「走哪个索引」 - 长期依赖
FORCE INDEX往往说明统计信息过期（ANALYZE TABLE orders可刷新）或索引设计不合理
联合索引中列顺序对回表的影响
顺序决定「筛选能力」和「覆盖能力」。错误的顺序会让索引既不能高效过滤，又无法避免回表。
假设经常执行：
SELECT user_id, amount FROM payments WHERE merchant_id = 1001 AND status = 'success' ORDER BY created_at DESC LIMIT 10;
建索引时若写成 (merchant_id, status, created_at)，就能覆盖 WHERE 和 ORDER BY，且 SELECT 的两列都在索引中（因为 user_id 是主键，自动包含；amount 不在索引里，仍需回表）——但如果业务允许，把 amount 加进索引尾部：(merchant_id, status, created_at, amount)，就彻底免回表。
所以顺序原则是：
- 等值查询列（
=或IN）放最左，高区分度优先 - 范围查询列（
>,BETWEEN,LIKE 'abc%'）放等值列之后，且只能有一个 - 排序列（
ORDER BY）紧接其后，保持方向一致（都ASC或都DESC） - 最后补上 SELECT 中需要但未被前面列覆盖的列，实现覆盖索引
回表不是玄学，是 B+Tree 结构和 InnoDB 存储格式共同决定的硬约束。想少回表，得盯着 EXPLAIN 的 key 和 Extra 看，而不是只看有没有 key 字段。
