rows是优化器基于统计信息预估的步骤输出行数，并非实际值，其准确性取决于统计信息质量与条件复杂度，失真时需更新统计或优化查询写法。

SQL执行计划里的 rows 字段，代表优化器预估该步骤将返回的行数，并非实际执行结果。它直接影响连接顺序、索引选择和是否走全表扫描等关键决策，但容易被误读为“准确值”或“实际返回量”。理解它的来源和局限性，比单纯看数字更重要。

rows 是怎么算出来的？

优化器基于统计信息（如表行数、列基数、直方图、索引分布）和谓词条件，通过内部模型估算每一步的输出行数。例如：

• WHERE status = 'paid'：若统计显示该值占全表 5%，而表有 100 万行，则 rows ≈ 5 万；
• JOIN t1 ON t1.id = t2.t1_id：会结合 t1 的过滤后行数、t2 的匹配比例、关联字段的选择性综合估算；
• 没有统计信息或数据倾斜严重时，估算可能偏差极大（比如预估 1 行，实际返回 10 万行）。

怎么看 rows 是否靠谱？

不能只盯单个 rows 值，要结合上下文交叉验证：

• 对比 table 行数：若 WHERE 条件后 rows 接近原表总行数，说明条件未有效过滤，可能缺索引或写法不当；
• 检查 key 和 type：rows 很小但 type=ALL（全表扫描），说明优化器误判了索引可用性；
• 观察 Extra 列：出现 "Using filesort" 或 "Using temporary" 且 rows 较大，往往意味着排序/分组开销高，需优化；
• 用 EXPLAIN ANALYZE（MySQL 8.0.18+ / PostgreSQL）对比实际行数（rows_examined 或 actual rows），差距超过一个数量级就值得深挖。

rows 明显不准？常见原因和应对

预估失真通常指向统计信息滞后或模型失效：

• 统计信息过期：大量 INSERT/DELETE/UPDATE 后未更新统计，运行 ANALYZE TABLE tbl_name（MySQL）或 VACUUM ANALYZE tbl_name（PostgreSQL）；
• 隐式类型转换：如 WHERE mobile = 13800138000（字段是 VARCHAR），导致索引失效，优化器被迫低估过滤效果；
• 函数/表达式过滤：如 WHERE DATE(create_time) = '2025-01-01'，无法利用索引，优化器缺乏可靠基数参考；
• 多列联合条件无复合统计：WHERE a=1 AND b=2，但只有单列统计，优化器按独立概率相乘估算，易出错；可建直方图或复合索引辅助。

别只盯着 rows，还要看 row_estimation_method

MySQL 8.0+ 可通过 SELECT @@optimizer_switch 查看是否启用 condition_fanout_filter 等新估算逻辑；PostgreSQL 中可通过 SET enable_seqscan = off 强制走索引，反推优化器是否因 rows 估算过低而放弃索引。真正有效的调优，是让 rows 回归合理区间，而非强行压制它变小。