MySQL 执行计划中 rows 数量的准确性解析：原理、影响因素与优化

在 MySQL SQL 调优中，EXPLAIN执行计划是核心工具，而其中的rows列（估算的扫描行数）更是优化器选择执行计划的关键参考 —— 它直接影响优化器对 “全表扫描 vs 索引扫描”“join 表顺序”“索引选择” 的判断。但实际使用中，开发者常困惑：rows值是精确值还是估算值？为什么有时和实际扫描行数相差悬殊？本文将从rows的计算原理出发，拆解准确性的影响因素，提供判断与优化方法，帮助读者正确利用rows进行 SQL 调优。

一、基础认知：执行计划中 rows 的本质 ——“估算值” 而非 “精确值”

首先需明确一个核心前提：MySQL 执行计划中的rows列，不是实际执行 SQL 时扫描的行数，而是优化器基于 “统计信息” 估算的 “需要扫描的行数”。其核心作用是为优化器提供 “成本评估依据”—— 优化器通过rows估算 “IO 成本”（读取数据页的数量）和 “CPU 成本”（处理数据的耗时），最终选择成本最低的执行计划。

1. rows 的计算逻辑：依赖 “统计信息”

MySQL 优化器无法实时遍历表或索引获取精确行数（否则会消耗大量资源，违背 “执行计划快速生成” 的初衷），而是依赖存储引擎（如 InnoDB、MyISAM）维护的 “统计信息” 进行估算，核心统计信息包括：

• 表级统计：表的总行数（TABLE_ROWS，可通过INFORMATION_SCHEMA.TABLES查询）、数据页数量、平均行长度；

• 索引级统计：索引的基数（CARDINALITY，索引列不重复值的数量，可通过SHOW INDEX FROM 表名查询）、索引树的深度、索引页数量；

• 列值分布统计：列值的直方图（MySQL 8.0 引入，记录列值的分布区间及每个区间的行数，用于优化范围查询的估算）。

例如，对于单表等值查询SELECT * FROM user WHERE age = 30，优化器的估算逻辑为：

rows ≈ 表总行数（TABLE_ROWS） / 索引列age的基数（CARDINALITY）

若表总行数 10000，age 的基数 100（即 age 有 100 个不同值，平均每个值对应 100 行），则rows估算为 100。

2. rows 准确性的 “价值边界”

不必追求rows与实际扫描行数完全一致 —— 优化器只需rows在 “合理误差范围”（通常认为 10 倍以内），就能正确选择执行计划。例如：

• 若实际扫描行数 100，rows估算为 80 或 120，优化器仍会选择正确的索引；

• 若rows估算为 1000（实际 100），可能导致优化器误判 “索引扫描成本高”，转而选择全表扫描，此时才需关注准确性问题。

二、影响 rows 准确性的核心因素：为什么有时准，有时不准？

rows的准确性由 “统计信息质量”“查询复杂度”“存储引擎特性” 三大维度决定，不同场景下准确性差异显著。

1. 哪些情况 rows 估算较准确？

当统计信息新鲜、查询逻辑简单、数据分布均匀时，rows估算值与实际值偏差通常小于 20%，典型场景包括：

（1）统计信息 “新鲜且完整”

• 刚执行过ANALYZE TABLE 表名（手动更新统计信息），或 MySQL 自动触发统计信息更新（如 InnoDB 在数据修改量超过 10% 时自动更新）；

• 表数据量小（如 < 1 万行），统计信息采样率足够高（小表默认全量采样，无抽样误差）。

示例：

对 1000 行的user表执行ANALYZE TABLE user后，执行EXPLAIN SELECT * FROM user WHERE id = 10（id为主键，基数 1000）：

• 优化器估算rows = 1（主键唯一，每个值对应 1 行），实际扫描行数也为 1，偏差 0%。

（2）简单查询 + 高选择性索引

• 单表查询，使用主键、唯一索引或高选择性普通索引（索引列重复值少，基数接近表行数）；

• 查询条件为等值查询（=）或极小范围查询（BETWEEN 1 AND 5），数据分布均匀。

示例：

user表有 10 万行，phone列唯一索引（基数 10 万），执行EXPLAIN SELECT * FROM user WHERE phone = '13800138000'：

• 优化器估算rows = 1，实际扫描行数 1，偏差 0%；

• 若phone列非唯一（基数 5 万，平均每个值对应 2 行），执行EXPLAIN SELECT * FROM user WHERE phone = '13800138000'，估算rows = 2，实际扫描行数通常为 1-3 行，偏差 < 50%。

（3）MySQL 8.0 + 的直方图优化

MySQL 8.0 引入 “列值直方图”，针对数据分布不均匀的列（如电商订单表的amount列，多数订单集中在 100-500 元，少数大额订单 > 10000 元），能更精准估算范围查询的rows值。

示例：

order表amount列有直方图，执行EXPLAIN SELECT * FROM order WHERE amount BETWEEN 200 AND 300：

• 无直方图时，优化器可能按 “平均分布” 估算（如总行数 10 万，amount基数 1000，估算rows = 100）；

• 有直方图时，优化器能识别 “200-300 元区间占比 30%”，估算rows = 30000，与实际行数偏差 < 10%。

2. 哪些情况 rows 估算容易不准？

当统计信息过期、查询复杂、数据分布极端时，rows偏差可能超过 10 倍甚至 100 倍，典型场景包括：

（1）统计信息 “过期或采样不足”

• 表数据频繁增删改（如每小时新增 1 万行），但未触发统计信息更新（InnoDB 默认修改量超 10% 才更新，大表可能延迟）；

• 大表（如 1000 万行以上）使用默认采样率（InnoDB 持久化统计信息默认采样innodb_stats_persistent_sample_pages = 20），采样误差导致基数估算偏差。

示例：

1000 万行的log表，create_time列普通索引，默认采样 20 个数据页：

• 实际create_time的基数为 100 万（每天新增约 3 万行，共 300 天数据），但采样时恰好命中 “某几天的重复数据”，导致优化器估算基数为 10 万；

• 执行EXPLAIN SELECT * FROM log WHERE create_time BETWEEN '2024-01-01' AND '2024-01-02'，实际扫描行数 3 万，估算rows = 30万（偏差 10 倍）。

（2）复杂查询逻辑

多表 join、子查询、复杂条件（OR、NOT IN、函数操作）会增加优化器的估算难度，导致rows偏差放大：

• 多表 join：优化器需估算 “驱动表与被驱动表的匹配行数”，若其中一个表的rows估算不准，会连锁影响整体 join 行数的估算；

• 子查询：尤其是IN (子查询)或EXISTS (子查询)，优化器可能简化子查询的估算逻辑，导致外层查询rows偏差；

• 函数操作：如WHERE DATE(create_time) = '2024-01-01'（索引失效，优化器只能按全表扫描估算，rows接近表总行数，与实际扫描行数偏差大）。

示例：

3 表 join 查询EXPLAIN SELECT * FROM a JOIN b ON ``a.id`` = b.a_id JOIN c ON ``b.id`` = c.b_id WHERE a.status = 1：

• 若a表status=1的实际行数 100，但优化器估算rows=1000（统计信息过期），则b表和c表的rows估算会基于 1000 行驱动，最终整体rows偏差可能达 10 倍以上。

（3）低选择性索引或极端数据分布

• 低选择性索引：索引列重复值多（如gender列，只有 “男 / 女” 两个值，基数 = 2），优化器按 “表总行数 / 基数” 估算rows（如 10 万行表，估算rows=5万），但实际某一性别可能占 80%（8 万行），偏差 60%；

• 极端数据分布：如user表age列，90% 的行集中在 18-30 岁，10% 在 30 岁以上，执行EXPLAIN SELECT * FROM user WHERE age > 30，优化器按 “平均分布” 估算rows=1万（10 万 ×10%），但实际可能因采样误差估算为 5 万（偏差 5 倍）。

（4）存储引擎特性差异

• MyISAM：统计信息存储在内存中，表关闭后会丢失，重启 MySQL 后需重新计算（可能导致临时估算偏差）；

• InnoDB：早期版本（<5.6）不支持持久化统计信息，重启后统计信息重置，大表估算偏差显著；MySQL 5.6 + 支持持久化统计信息（innodb_stats_persistent = ON），但默认采样率仍可能不足。

三、如何判断 rows 估算的准确性？

判断rows是否 “足够准确”，核心是对比 “执行计划的rows” 与 “实际扫描行数”，常用方法有 3 种：

1. 方法 1：用SHOW PROFILE查看实际扫描行数

SHOW PROFILE可查看 SQL 执行的详细步骤，包括 “实际扫描的行数”（Rows_examined）：

-- 1. 开启profiling

SET profiling = 1;

-- 2. 执行目标SQL

SELECT * FROM user WHERE age BETWEEN 20 AND 30;

-- 3. 查看profile结果

SHOW PROFILE FOR QUERY 1;  -- Query 1为SQL的编号，可通过SHOW PROFILES查看

-- 关键输出：Rows_examined: 1200（实际扫描行数）

-- 对比执行计划的rows：若EXPLAIN中rows=1000，偏差20%，属于可接受范围；若rows=5000，偏差4倍，需优化

2. 方法 2：用EXPLAIN ANALYZE（MySQL 8.0.18+）直接对比

MySQL 8.0.18 引入EXPLAIN ANALYZE，会实际执行 SQL（但不返回结果集），同时输出 “估算 rows” 与 “实际 rows”，是最直观的判断方法：

EXPLAIN ANALYZE

SELECT * FROM user WHERE age BETWEEN 20 AND 30;

-- 典型输出（关键部分）：

-- -> Index Range Scan on user using idx_age over (age between 20 and 30)

--    (cost=120.00 rows=1000) (actual time=0.022..0.150 rows=1200 loops=1)

-- 解读：估算rows=1000，实际rows=1200，偏差20%，准确性可接受

3. 方法 3：小数据量手动对比

对于数据量较小的表（如 < 10 万行），可直接执行 SQL 并计数，与EXPLAIN的rows对比：

-- 1. 查看执行计划的rows

EXPLAIN SELECT * FROM user WHERE age BETWEEN 20 AND 30;  -- 假设rows=1000

-- 2. 手动计数实际行数

SELECT COUNT(*) FROM user WHERE age BETWEEN 20 AND 30;  -- 假设结果=1200

-- 对比：偏差20%，可接受；若计数=5000，偏差5倍，需优化

四、优化 rows 估算准确性的实用策略

当rows偏差过大（如超过 10 倍），导致优化器选择错误执行计划（如该用索引却全表扫描）时，可通过以下策略优化：

1. 策略 1：更新统计信息 —— 最直接的方法

通过ANALYZE TABLE手动更新表的统计信息，适用于统计信息过期的场景：

-- 1. 基础更新：更新指定表的统计信息

ANALYZE TABLE user, order;

-- 2. 进阶：InnoDB强制全量采样（大表慎用，可能耗时）

-- 临时设置采样页数量为表的总数据页数（需先查询总页数）

SELECT CEIL(data_length / @@innodb_page_size) AS total_pages FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'user';

SET innodb_stats_persistent_sample_pages = 1000;  -- 假设总页数1000

ANALYZE TABLE user;

SET innodb_stats_persistent_sample_pages = 20;  -- 恢复默认值，避免后续性能影响

注意：ANALYZE TABLE会对表加 “读锁”（InnoDB 在 MySQL 8.0 中已优化为轻量级锁，不阻塞 DML），大表（如 1000 万行以上）建议在业务低峰期执行。

2. 策略 2：调整统计信息采样率 —— 针对大表

InnoDB 的统计信息采样率由以下参数控制，可根据表大小调整：

• innodb_stats_persistent_sample_pages：持久化统计信息的采样页数量（默认 20），大表可增大至 100-1000，提升基数估算准确性；

• innodb_stats_transient_sample_pages：临时统计信息的采样页数量（默认 8），若禁用持久化统计信息（innodb_stats_persistent = OFF），需调整此参数。

示例：

对 1000 万行的log表，永久调整采样页数量：

-- 1. 全局调整（需重启MySQL生效）

SET GLOBAL innodb_stats_persistent_sample_pages = 200;

-- 修改配置文件my.cnf，避免重启失效

innodb_stats_persistent_sample_pages = 200

-- 2. 仅对指定表调整（MySQL 8.0+支持）

ALTER TABLE log SET STATISTICS_SAMPLE_PAGES = 200;

3. 策略 3：优化查询语句 —— 降低估算复杂度

复杂查询是rows偏差的主要诱因，可通过简化查询逻辑提升准确性：

• 避免函数操作索引列：如将DATE(create_time) = '2024-01-01'改为create_time BETWEEN '2024-01-01 00:00:00' AND '2024-01-01 23:59:59'，利用索引精准估算；

• 拆分复杂 join：将 3 表以上 join 拆分为 “子查询 + 关联”，或用STRAIGHT_JOIN强制指定 join 顺序（减少优化器的估算误差）；

• 替换低选择性索引：如gender列不适合建索引，直接用全表扫描，避免优化器基于低选择性索引做错误估算。

4. 策略 4：使用直方图优化数据分布估算

MySQL 8.0 + 支持为列创建直方图，针对数据分布不均匀的列（如amount、create_time），能显著提升范围查询的rows准确性：

-- 1. 为order表的amount列创建直方图

ANALYZE TABLE order UPDATE HISTOGRAM ON amount;

-- 2. 查看直方图信息

SELECT * FROM INFORMATION_SCHEMA.COLUMN_STATISTICS WHERE TABLE_NAME = 'order' AND COLUMN_NAME = 'amount';

-- 3. 执行范围查询，查看rows估算

EXPLAIN ANALYZE SELECT * FROM order WHERE amount BETWEEN 200 AND 300;

-- 此时估算rows与实际rows偏差通常<10%

5. 策略 5：升级 MySQL 版本 —— 享受原生优化

MySQL 新版本对统计信息和估算算法持续优化：

• MySQL 8.0：引入直方图、动态采样率、更精准的 join 行数估算；

• MySQL 5.7：优化 InnoDB 持久化统计信息，减少重启后的偏差；

• 若使用 MySQL 5.6 及以下版本，升级到 8.0 可显著提升rows估算准确性。

五、总结：理性看待 rows 准确性，聚焦 “优化器选择” 而非 “绝对精确”

MySQL 执行计划中的rows是 “估算值”，其核心价值是帮助优化器选择 “成本最低的执行计划”，而非提供 “精确的扫描行数”。实际调优中，需把握以下原则：

1. 可接受偏差范围：若rows与实际行数偏差 < 10 倍，且优化器选择了正确的执行计划（如用索引而非全表扫描），无需过度优化；

2. 优先解决 “严重偏差”：仅当rows偏差导致优化器选择错误执行计划（如该用主键索引却全表扫描）时，才需通过更新统计信息、调整采样率等方式优化；

3. 结合其他指标判断：rows需与执行计划的type（访问类型，如ref、range、ALL）、key（使用的索引）、Extra（额外信息，如Using index）结合，综合评估 SQL 性能，而非单一依赖rows。

最终，掌握rows的估算原理与优化方法，能让开发者更高效地利用执行计划定位 SQL 性能瓶颈，实现 “精准调优” 而非 “盲目优化”。

推荐学习书籍 《CDA一级教材》适合CDA一级考生备考，也适合业务及数据分析岗位的从业者提升自我。完整电子版已上线CDA网校，累计已有10万+在读~ !

免费加入阅读：https://edu.cda.cn/goods/show/3151?targetId=5147&preview=0