EXPLAIN 的 rows 值不准是因为它基于采样估算而非真实扫描：InnoDB 默认仅随机采样20个（持久化开启时）或8个（关闭时）索引页，通过插值推算整棵树基数；数据倾斜严重时（如95% status='pending'），采样易漏稀有值，导致Cardinality低估一个数量级，进而使rows失真。
EXPLAIN 的 rows 值为什么总是不准
因为 rows 是优化器根据采样估算出来的，不是真实扫描行数。InnoDB 默认只随机采样 innodb_stats_persistent_sample_pages 个叶子页（ON 时默认 20，OFF 时默认 8），再插值推算整棵树的基数。数据倾斜严重时——比如 status 字段 95% 是 'pending'——采样可能完全漏掉稀有值，导致 Cardinality 低估一个数量级。
- 用
SHOW INDEX FROM orders查看Cardinality，若它和实际唯一值差 10 倍以上，rows几乎必然失真 -
ANALYZE TABLE orders能刷新统计，但会加 MDL 锁，大表执行耗时长，线上不敢频繁跑 - 即使刚执行完
ANALYZE，如果紧接着批量写入，统计又立刻滞后
FORCE INDEX 为什么上线就炸
硬指定索引看似简单，实则把“估算风险”转成“强依赖风险”。一旦索引被删、重命名或字段顺序调整，SQL 直接报错 ERROR 1176 (HY000): Key 'idx_user_status' doesn't exist in table 'orders'，不会降级为其他索引或全表扫描。
- MyBatis 或 JDBC 动态拼 SQL 时，若没做
INFORMATION_SCHEMA.STATISTICS校验，上线即故障 - 索引列分布变化后（如
user_id新增大量测试账号），FORCE INDEX仍强制走低效范围扫描 - 复合索引中前导列未出现在 WHERE 条件里，
FORCE INDEX也无效（例如索引是(a,b)，但查询只用了b）
optimizer_trace 要看哪几块关键输出
开 SET optimizer_trace='enabled=on' 后查 SELECT * FROM information_schema.OPTIMIZER_TRACE，重点盯三处：
-
range_analysis里的rows和cost：对比不同索引的预估行数是否离谱 -
considered_execution_plans中每个 plan 的cost构成：看是io_cost高还是cpu_cost高，判断瓶颈在磁盘还是计算 -
analyzing_range_alternatives下的index_dives_for_eq_ranges是否为false：若关了深度探测，优化器仅靠统计估算，极易误判
真正该修的不是 SQL，而是统计信息的更新机制
临时加 FORCE INDEX 或改 SQL 只是止血，根治得让优化器下次别再算错。核心矛盾在于：采样机制天生不准 + 自动更新滞后 + 业务写入节奏快于统计刷新频率。
- 对高频变更表，设
innodb_stats_persistent = ON并调高innodb_stats_persistent_sample_pages（如 100），提升采样代表性 - 避免在业务高峰跑
ANALYZE TABLE；可结合 binlog 位置，在从库空闲时段异步触发 - 监控
mysql.innodb_table_stats表的last_update时间，发现滞后超 1 小时就告警
最麻烦的从来不是“哪个索引更快”，而是“优化器凭什么信这个数字”。它信的不是数据，是那几十页采样出来的幻影。
