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字段。
