在 MySQL SQL 调优中，EXPLAIN执行计划是核心工具，而其中的rows列（估算的扫描行数）更是优化器选择执行计划的关键参考 —— 它直接影响优化器对 “全表扫描 vs 索引扫描”“join 表顺序”“索引选择” 的判断。但实际使用中，开发者常困惑：rows值是精确值还是估算值？为什么有时和实际扫描行数相差悬殊？本文将从rows的计算原理出发，拆解准确性的影响因素，提供判断与优化方法，帮助读者正确利用rows进行 SQL 调优。
首先需明确一个核心前提：MySQL 执行计划中的rows列，不是实际执行 SQL 时扫描的行数，而是优化器基于 “统计信息” 估算的 “需要扫描的行数”。其核心作用是为优化器提供 “成本评估依据”—— 优化器通过rows估算 “IO 成本”（读取数据页的数量）和 “CPU 成本”（处理数据的耗时），最终选择成本最低的执行计划。
MySQL 优化器无法实时遍历表或索引获取精确行数（否则会消耗大量资源，违背 “执行计划快速生成” 的初衷），而是依赖存储引擎（如 InnoDB、MyISAM）维护的 “统计信息” 进行估算，核心统计信息包括：
表级统计：表的总行数（TABLE_ROWS，可通过INFORMATION_SCHEMA.TABLES查询）、数据页数量、平均行长度；
索引级统计：索引的基数（CARDINALITY，索引列不重复值的数量，可通过SHOW INDEX FROM 表名查询）、索引树的深度、索引页数量；
例如，对于单表等值查询SELECT * FROM user WHERE age = 30，优化器的估算逻辑为：
rows ≈ 表总行数（TABLE_ROWS） / 索引列age的基数（CARDINALITY）
若表总行数 10000，age 的基数 100（即 age 有 100 个不同值，平均每个值对应 100 行），则rows估算为 100。
不必追求rows与实际扫描行数完全一致 —— 优化器只需rows在 “合理误差范围”（通常认为 10 倍以内），就能正确选择执行计划。例如：
若实际扫描行数 100，rows估算为 80 或 120，优化器仍会选择正确的索引；
若rows估算为 1000（实际 100），可能导致优化器误判 “索引扫描成本高”，转而选择全表扫描，此时才需关注准确性问题。
rows的准确性由 “统计信息质量”“查询复杂度”“存储引擎特性” 三大维度决定，不同场景下准确性差异显著。
当统计信息新鲜、查询逻辑简单、数据分布均匀时，rows估算值与实际值偏差通常小于 20%，典型场景包括：
刚执行过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%。示例：
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%。
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%。
当统计信息过期、查询复杂、数据分布极端时，rows偏差可能超过 10 倍甚至 100 倍，典型场景包括：
表数据频繁增删改（如每小时新增 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 倍）。
多表 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 倍以上。低选择性索引：索引列重复值多（如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 倍）。
InnoDB：早期版本（<5.6）不支持持久化统计信息，重启后统计信息重置，大表估算偏差显著；MySQL 5.6 + 支持持久化统计信息（innodb_stats_persistent = ON），但默认采样率仍可能不足。
判断rows是否 “足够准确”，核心是对比 “执行计划的rows” 与 “实际扫描行数”，常用方法有 3 种：
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倍，需优化
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%，准确性可接受
对于数据量较小的表（如 < 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偏差过大（如超过 10 倍），导致优化器选择错误执行计划（如该用索引却全表扫描）时，可通过以下策略优化：
通过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 万行以上）建议在业务低峰期执行。
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;
复杂查询是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 顺序（减少优化器的估算误差）；
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%
MySQL 新版本对统计信息和估算算法持续优化：
若使用 MySQL 5.6 及以下版本，升级到 8.0 可显著提升rows估算准确性。
MySQL 执行计划中的rows是 “估算值”，其核心价值是帮助优化器选择 “成本最低的执行计划”，而非提供 “精确的扫描行数”。实际调优中，需把握以下原则：
可接受偏差范围：若rows与实际行数偏差 < 10 倍，且优化器选择了正确的执行计划（如用索引而非全表扫描），无需过度优化；
优先解决 “严重偏差”：仅当rows偏差导致优化器选择错误执行计划（如该用主键索引却全表扫描）时，才需通过更新统计信息、调整采样率等方式优化；
结合其他指标判断：rows需与执行计划的type（访问类型，如ref、range、ALL）、key（使用的索引）、Extra（额外信息，如Using index）结合，综合评估 SQL 性能，而非单一依赖rows。
最终，掌握rows的估算原理与优化方法，能让开发者更高效地利用执行计划定位 SQL 性能瓶颈，实现 “精准调优” 而非 “盲目优化”。
数据分析咨询请扫描二维码
若不方便扫码，搜微信号：CDAshujufenxi
B+树作为数据库索引的核心数据结构，其高效的查询、插入、删除性能，离不开节点间指针的合理设计。在日常学习和数据库开发中，很 ...
2026-01-30在数据库开发中，UUID（通用唯一识别码）是生成唯一主键、唯一标识的常用方式，其标准格式包含4个短横线（如550e8400-e29b-41d4- ...
2026-01-30商业数据分析的价值落地，离不开标准化、系统化的总体流程作为支撑；而CDA（Certified Data Analyst）数据分析师，作为经过系统 ...
2026-01-30在数据分析、质量控制、科研实验等场景中，数据波动性（离散程度）的精准衡量是判断数据可靠性、稳定性的核心环节。标准差（Stan ...
2026-01-29在数据分析、质量检测、科研实验等领域，判断数据间是否存在本质差异是核心需求，而t检验、F检验是实现这一目标的经典统计方法。 ...
2026-01-29统计制图（数据可视化）是数据分析的核心呈现载体，它将抽象的数据转化为直观的图表、图形，让数据规律、业务差异与潜在问题一目 ...
2026-01-29箱线图（Box Plot）作为数据分布可视化的核心工具，能清晰呈现数据的中位数、四分位数、异常值等关键统计特征，广泛应用于数据分 ...
2026-01-28在回归分析、机器学习建模等数据分析场景中，多重共线性是高频数据问题——当多个自变量间存在较强的线性关联时，会导致模型系数 ...
2026-01-28数据分析的价值落地，离不开科学方法的支撑。六种核心分析方法——描述性分析、诊断性分析、预测性分析、规范性分析、对比分析、 ...
2026-01-28在机器学习与数据分析领域，特征是连接数据与模型的核心载体，而特征重要性分析则是挖掘数据价值、优化模型性能、赋能业务决策的 ...
2026-01-27关联分析是数据挖掘领域中挖掘数据间潜在关联关系的经典方法，广泛应用于零售购物篮分析、电商推荐、用户行为路径挖掘等场景。而 ...
2026-01-27数据分析的基础范式，是支撑数据工作从“零散操作”走向“标准化落地”的核心方法论框架，它定义了数据分析的核心逻辑、流程与目 ...
2026-01-27在数据分析、后端开发、业务运维等工作中，SQL语句是操作数据库的核心工具。面对复杂的表结构、多表关联逻辑及灵活的查询需求， ...
2026-01-26支持向量机（SVM）作为机器学习中经典的分类算法，凭借其在小样本、高维数据场景下的优异泛化能力，被广泛应用于图像识别、文本 ...
2026-01-26在数字化浪潮下，数据分析已成为企业决策的核心支撑，而CDA数据分析师作为标准化、专业化的数据人才代表，正逐步成为连接数据资 ...
2026-01-26数据分析的核心价值在于用数据驱动决策，而指标作为数据的“载体”，其选取的合理性直接决定分析结果的有效性。选对指标能精准定 ...
2026-01-23在MySQL查询编写中，我们习惯按“SELECT → FROM → WHERE → ORDER BY”的语法顺序组织语句，直觉上认为代码顺序即执行顺序。但 ...
2026-01-23数字化转型已从企业“可选项”升级为“必答题”，其核心本质是通过数据驱动业务重构、流程优化与模式创新，实现从传统运营向智能 ...
2026-01-23CDA持证人已遍布在世界范围各行各业，包括世界500强企业、顶尖科技独角兽、大型金融机构、国企事业单位、国家行政机关等等，“CDA数据分析师”人才队伍遵守着CDA职业道德准则，发挥着专业技能，已成为支撑科技发展的核心力量。 ...
2026-01-22在数字化时代，企业积累的海量数据如同散落的珍珠，而数据模型就是串联这些珍珠的线——它并非简单的数据集合，而是对现实业务场 ...
2026-01-22
京公网安备 11010802034615号
经营许可证编号：京B2-20210330
