如何分析执行计划中的rows估算值？统计信息更新与ANALYZE TABLE有什么关联

执行计划中的rows估算值是数据库优化器基于现有统计信息，预估查询需要扫描的行数，这个数值直接决定了优化器选择的索引和查询路径，对查询性能影响很大。如果rows估算值偏差过大，很可能导致优化器选错索引，引发慢查询问题。

rows估算值的计算逻辑

rows估算值并非实际扫描行数，而是优化器根据表、索引的统计信息推导出来的预估值，核心计算依据包含以下几个方面：

• 表的 total_rows：即表的总行数，来自统计信息中的记录
• 索引的 cardinality：索引不同值的个数，反映索引的区分度
• 查询条件的过滤性：比如等值查询、范围查询的预估过滤比例

以等值查询为例，优化器通常会用 total_rows 除以对应索引的 cardinality，得到单条条件的预估扫描行数。如果查询有多个条件，还会结合多列统计信息调整预估值。

统计信息对rows估算的影响

统计信息是rows估算的基础，当统计信息过期时，rows估算值就会出现明显偏差，常见场景有：

• 表经过大量插入、删除、更新操作后，总行数变化但统计信息未更新
• 索引的区分度发生变化，比如某列原本值很分散，后来大量重复值插入
• 统计信息采样比例过低，无法反映表的真实数据分布

我们可以通过SHOW TABLE STATUS LIKE '表名'查看表的统计信息，其中Rows字段就是统计信息记录的总行数，和实际的SELECT COUNT(*)结果可能不一致。

ANALYZE TABLE的作用与使用

ANALYZE TABLE是更新表统计信息的核心命令，执行后会重新采样表的数据和索引，更新优化器依赖的统计信息，从而让rows估算值更准确。

基本使用语法

执行以下命令即可更新指定表的统计信息：

-- 分析单个表
ANALYZE TABLE user_order;
-- 分析多个表
ANALYZE TABLE user_info, order_detail;

执行后的效果

执行ANALYZE TABLE后，再次查看执行计划，rows估算值会基于新的统计信息重新计算，通常和实际扫描行数的偏差会明显缩小。我们可以通过对比更新前后的执行计划验证效果：

-- 更新统计信息前查看执行计划
EXPLAIN SELECT * FROM user_order WHERE user_id = 1001;
-- 更新统计信息
ANALYZE TABLE user_order;
-- 更新后再次查看执行计划
EXPLAIN SELECT * FROM user_order WHERE user_id = 1001;

注意事项

• ANALYZE TABLE会对表加读锁，大表执行时可能会影响短暂的查询，建议在业务低峰期执行
• InnoDB引擎下ANALYZE TABLE是预估统计，不是全量扫描，采样比例可以通过innodb_stats_sample_pages参数调整
• 如果表数据变化不频繁，不需要频繁执行ANALYZE TABLE，通常数据变化超过10%到20%时再执行即可
• 部分云数据库会自动触发统计信息更新，不需要手动执行ANALYZE TABLE，具体可以查看对应数据库的产品文档

当遇到查询突然变慢、执行计划异常的情况，可以先检查rows估算值是否偏差过大，再确认统计信息是否过期，必要时执行ANALYZE TABLE更新统计信息，通常能解决大部分因估算偏差导致的性能问题。

MySQL执行计划rows估算值统计信息ANALYZE_TABLE修改时间：2026-06-28 09:09:25