MySQL执行计划中rows的计算逻辑：从原理到实践

MySQL 执行计划中 rows 的计算逻辑：从原理到实践

在 MySQL 数据库的查询优化中，执行计划（EXPLAIN输出）是开发者和 DBA 分析查询性能的核心工具。其中，rows列作为执行计划的关键指标，代表优化器估计的当前操作需要扫描的行数。这个数值直接反映了查询的效率 —— 行数越少，查询通常越高效。但很多人对这个数值的计算逻辑感到困惑：它究竟是怎么来的？为何有时会与实际扫描行数相差较大？本文将从原理到实践，全面解析 MySQL 执行计划中rows的计算逻辑。

一、rows 的核心作用：优化器的 “决策依据”

在深入计算逻辑前，需先明确rows的本质：它是 MySQL 优化器基于统计信息和数据分布规律，对查询执行过程中需要访问的行数的 “预测值”，而非实际执行时的真实扫描行数。

优化器的核心任务是选择最优执行计划（如全表扫描还是索引扫描、多表连接的顺序等），而rows值是优化器判断成本的重要依据。例如，对于一个简单的过滤查询，优化器会比较 “全表扫描估计的 rows” 和 “索引扫描估计的 rows”，选择成本更低的方案。因此，rows的准确性直接影响优化器决策的合理性。

二、rows 计算的核心依据：统计信息

MySQL 优化器之所以能 “估计” 行数，依赖于数据库收集的统计信息（statistics）。这些信息存储在系统表中（如mysql.innodb_index_stats、mysql.innodb_table_stats），记录了表、索引、列的数据分布特征。统计信息是rows计算的 “原始数据”，主要包括以下关键指标：

1. 表级统计信息

总行数（table_rows）：表中记录的估计总数量。对于 InnoDB 表，这个值并非实时精确值，而是通过采样计算的近似值（具体采样逻辑后文详述）。
数据长度（data_length）：表数据占用的存储空间，用于辅助判断表的 “大小”。

2. 索引级统计信息

基数（Cardinality）：索引列中不重复值的估计数量。例如，一个性别列（值为 “男”“女”）的基数约为 2，而一个用户 ID 列的基数接近表的总行数。基数直接影响索引的 “选择性”（Selectivity，即不重复值占总行数的比例），选择性越高（基数越大），索引过滤效果越好。
索引深度（index_depth）：索引 B + 树的高度，影响索引扫描的 IO 成本。

3. 列级统计信息

值分布（value distribution）：部分列的直方图（Histogram）统计，记录列值的分布范围和频率。例如，一个订单金额列的直方图可能显示 “0-100 元占 60%，100-500 元占 30%” 等分布特征，帮助优化器更精准地估计过滤条件后的行数。

三、不同操作场景下 rows 的具体计算逻辑

rows的计算方式并非一成不变，而是根据查询操作的类型（如全表扫描、索引扫描、连接查询）动态调整。以下是常见场景的计算逻辑：

1. 全表扫描（type: ALL）

当查询无法使用索引（如无合适索引、条件过于宽泛）时，优化器会选择全表扫描，此时rows的估计值主要基于表级统计信息中的总行数（table_rows）。

例如，对于一张user表，table_rows统计值为 10000，执行EXPLAIN SELECT * FROM user时，rows列通常会接近 10000。但需注意：table_rows是 InnoDB 通过采样计算的近似值（默认采样 8 个数据页），若表数据分布不均或采样偏差，rows可能与实际总行数存在差异。

2. 索引扫描（type: ref、range、index 等）

当查询使用索引时，rows的计算依赖于索引的基数、选择性及查询条件，核心公式可简化为：

估计扫描行数 = 索引过滤后的基数 × 数据分布系数 &#x20;

具体场景如下：

等值查询（ref 类型）：如WHERE age = 30，优化器会先通过索引统计获取age列的基数，计算 “值 = 30” 的选择性（即该值在列中的占比），再用表总行数乘以选择性，得到估计行数。例：

例：user表总行数 10000，age列基数为 50（假设年龄分布在 18-67 岁，共 50 个可能值），则 “age=30” 的选择性约为 1/50，估计行数为 10000 × (1/50) = 200。
范围查询（range 类型）：如WHERE price BETWEEN 100 AND 500，优化器会结合索引的直方图统计（若启用）或索引值的分布范围，估算范围内的值占总基数的比例，再乘以总行数。例：

例：product表总行数 50000，price列索引基数为 10000，若统计显示 “100-500 元” 的价格占比约 20%，则估计行数为 50000 × 20% = 10000。
索引全扫描（index 类型）：当查询需要扫描整个索引（如SELECT COUNT(*) FROM user USE INDEX(age_idx)），rows值接近索引的总记录数，该值基于索引的统计信息（如innodb_index_stats中的sum_of_rows）。

3. 连接查询（JOIN）

多表连接时，rows的计算更为复杂，优化器需估计每一步连接的 “驱动表” 和 “被驱动表” 的扫描行数，核心逻辑基于嵌套循环连接的成本模型：

总估计行数 = 驱动表估计行数 × 被驱动表单条驱动记录的匹配行数 &#x20;

例如，SELECT * FROM order o JOIN user u ON o.user_id = ``u.id，优化器会先确定驱动表（如order表，估计行数 1000），再根据user表中id索引的基数，计算每条order记录匹配的user记录数（假设id是主键，基数 = 总行数，匹配行数 = 1），则总rows估计为 1000 × 1 = 1000。

四、影响 rows 估计准确性的关键因素

实际使用中，rows估计值与真实值的偏差往往源于以下因素，需重点关注：

1. 统计信息过时或缺失

MySQL 的统计信息默认通过采样更新（InnoDB 默认每 10% 数据变更触发自动更新，或通过ANALYZE TABLE手动更新）。若表数据频繁插入、删除或更新，统计信息未及时更新，会导致table_rows、基数等指标失真，进而影响rows估计。

例如，一张表刚插入 10 万条新数据但未更新统计信息，优化器仍使用旧的table_rows（如 5 万），此时rows估计会远小于实际值。

2. 数据分布极端不均

当列数据存在 “长尾分布”（如某值占比 90%，其他值共占 10%），采样统计可能无法准确捕捉分布特征。例如，status列中 90% 的值为 “normal”，10% 为 “error”，优化器基于采样可能误判 “status='normal'” 的选择性为 50%，导致rows估计偏差。

3. 索引失效或使用不当

若索引存在重复值过多（选择性低）、索引碎片严重等问题，优化器可能低估或高估索引扫描的行数。例如，对一个选择性极低的索引（如性别列）执行查询，优化器可能认为 “索引扫描 rows” 与 “全表扫描 rows” 接近，进而选择全表扫描，导致执行计划不符合预期。

4. 复杂查询的估计误差累积

对于包含子查询、聚合函数（GROUP BY）、排序（ORDER BY）的复杂查询，优化器需对多个步骤的rows进行估计，误差会逐步累积，导致最终rows值与实际偏差较大。

五、优化 rows 估计准确性的实践方法

要让rows值更接近实际扫描行数，需从统计信息维护、数据设计和查询优化三方面入手：

1. 及时更新统计信息

对频繁变更的表定期执行ANALYZE TABLE table_name，强制更新统计信息（InnoDB 会重新采样计算table_rows、基数等）。
调整统计信息采样参数：通过innodb_stats_persistent_sample_pages（持久化统计采样页数量，默认 20）或innodb_stats_transient_sample_pages（临时统计采样页数量，默认 8）提高采样精度（需权衡性能开销）。

2. 优化数据分布与索引设计

避免在低选择性列上创建索引（如性别、状态等），此类索引对rows估计和查询效率提升有限。
对高选择性列（如用户 ID、订单号）建立索引，并通过SHOW INDEX FROM table_name定期检查索引基数是否合理。

3. 结合实际执行计划调优查询

若rows估计值与实际扫描行数偏差较大（可通过SHOW PROFILE或慢查询日志查看实际行数），尝试改写查询（如调整过滤条件顺序、避免子查询嵌套过深）。
对复杂连接查询，通过STRAIGHT_JOIN指定连接顺序，避免优化器因rows估计错误选择低效连接方式。

六、案例：从 rows 异常看查询优化

某电商平台的订单查询 SQL 执行缓慢，EXPLAIN输出显示rows估计为 1000，但实际扫描行数达 10 万。排查发现：

订单表order近期新增 50 万条数据，但未执行ANALYZE TABLE，table_rows仍为旧值 10 万，导致优化器低估总行数；
过滤条件WHERE create_time > '2023-01-01'使用的create_time索引存在大量碎片，基数统计失真，优化器误判范围查询的选择性为 1%（实际为 20%）。

解决方法：

执行ANALYZE TABLE order更新统计信息，table_rows修正为 60 万；
重建create_time索引（ALTER TABLE order REBUILD INDEX create_time_idx），修复碎片并更新基数；
优化后，rows估计值为 12000（60 万 × 20%），与实际扫描行数（11 万）接近，优化器选择了更合理的索引扫描计划，查询性能提升 80%。

结语

MySQL 执行计划中的rows值是优化器基于统计信息和数据分布的 “智能预测”，其计算逻辑贯穿查询执行的全流程。理解rows的来源、影响因素及优化方法，不仅能帮助开发者快速定位查询性能瓶颈，更能深入掌握 MySQL 优化器的工作原理。在实际工作中，需结合EXPLAIN输出、统计信息维护和数据特征分析，让rows成为查询优化的 “指路明灯”，而非误导决策的 “迷雾”。