执行计划有 rows 数字，但它不是本次查询真实扫描行数。理解估计和观察之间的区别很关键。
本文使用MySQL 5.6、InnoDB 与独立测试数据库。数据库研究要同时观察表结构、数据分布和实际语句。本文讨论 InnoDB（事务存储引擎），不把其他存储引擎或后续版本特性当作相同行为。
1. 从现象推到机制
优化器根据统计信息估算访问成本，选择索引和连接顺序。数据分布偏斜、统计陈旧与条件相关性都可能影响估算。MySQL 5.6 没有后续版本的 EXPLAIN ANALYZE，不能把新命令放进这套环境。
图中的四个节点分别表示查询条件、统计估算、执行计划、运行证据。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
先保留 EXPLAIN，再结合慢日志、查询结果和可用运行统计分析。比较前后应使用相同数据与查询参数，避免缓存状态变化掩盖问题。
1
2
3
EXPLAIN SELECT id, amount FROM orders
WHERE owner_id = 7 AND status = 1;
SHOW INDEX FROM orders;
先保存建表语句、索引与隔离级别，再准备固定演示数据。并发行为使用两个独立连接按顺序执行；执行计划、锁等待和最终数据需要结合，单看查询耗时不足以解释原因。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 小表选择全表扫描 | 可能是合理成本选择 |
| 统计信息与分布不符 | 估算可能偏离实际工作量 |
| 添加索引后耗时变化 | 仍需排除缓存与负载差异 |
对照 1：小表选择全表扫描
可能是合理成本选择。观察时记录表大小与返回比例。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：统计信息与分布不符
估算可能偏离实际工作量。观察时记录估计行数与可取得的运行证据。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：添加索引后耗时变化
仍需排除缓存与负载差异。观察时记录相同参数下的多次观察。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
优化目标是减少真实业务成本，不是让每条查询都显示使用索引。返回大比例数据时，全表扫描可能比反复回表更合适。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“添加索引后耗时变化”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
