rows是优化器基于统计信息估算的扫描行数，并非实际执行时的真实扫描量；其准确性依赖数据分布均匀性和采样代表性，可通过analyze table手动更新统计信息，必要时调高innodb_stats_persistent_sample_pages或启用直方图。
rows 是估算值，不是实际扫描数
rows 列出现在 EXPLAIN 输出里，代表优化器基于统计信息“猜”的扫描行数。它不等于执行时真实读取的行，也不等于最终返回的行——只是成本估算的中间变量。比如你查一个时间范围，rows=5 可能是优化器从索引页采样后，推断该范围只覆盖 5 条记录；但实际数据倾斜严重（新数据全在最近 1 小时），真实扫描可能上千行。
这个估算依赖两个前提：数据分布均匀、采样页有代表性。现实里这两点常不成立，尤其在以下场景：
- 字段存在明显倾斜（如 status 字段 95% 是 'active'）
- 查询条件带函数（WHERE DATE(create_time) = '2026-05-01'）
- 使用模糊前缀匹配（LIKE '%abc'），索引无法下推，优化器直接放弃用统计信息
ANALYZE TABLE 才是真正刷新 rows 估算的手段
MySQL 不会实时更新统计信息，ANALYZE TABLE 是唯一能立即强制重采样的命令。它不是“刷新行数”，而是重新估算索引的 cardinality、键值分布、叶子页数量等，并写入 mysql.innodb_index_stats 系统表。
常见必须手动执行的信号包括：
- SHOW INDEX FROM t 中某索引的 Cardinality 为 0 或明显偏离实际唯一值数量
- 新增索引后，EXPLAIN 显示没走这个索引，且 rows 极小（如 1）
- 批量导入百万级数据后，EXPLAIN 的 rows 和 COUNT(*) 差距超 3 倍
- information_schema.TABLES.TABLE_ROWS 和实际行数偏差大，且已确认不是 MVCC 可见性问题
采样机制决定了 rows 本身就有误差
InnoDB 默认只采样 innodb_stats_sample_pages 个叶子页（MySQL 5.7 默认 20，8.0 默认 20），每页再随机抽部分记录。这意味着：
- 两次 ANALYZE TABLE 可能得出略有差异的 cardinality，rows 自然浮动
- 大表中默认采样页数太少，容易低估高选择性字段的过滤能力（例如新增一个唯一索引，但采样没落到对应页，Cardinality 仍显示偏低）
- 可临时调高采样页数：SET GLOBAL innodb_stats_sample_pages = 100，但仅对后续 ANALYZE 生效，且耗时上升明显
注意：调高参数不能解决根本问题。若字段分布极不均匀（如订单金额集中在几个区间），光靠采样不够，得配合 MySQL 8.0+ 的直方图：ANALYZE TABLE t UPDATE HISTOGRAM ON amount WITH 16 BUCKETS。
自动更新不可靠，别依赖 innodb_stats_auto_recalc
innodb_stats_auto_recalc=ON 并不等于“数据一变就更新”。它只在满足两个条件时触发：
- 表变更行数超过预估总行数的 10%（注意：这个“预估总行数”来自旧统计，本身可能不准）
- 表有二级索引（无二级索引的表不会触发）
更关键的是：该机制只对建表时指定 STATS_AUTO_RECALC=1 的表生效。已有表必须显式执行：ALTER TABLE t STATS_AUTO_RECALC=1。而像 OPTIMIZE TABLE 或 ALTER TABLE ... ENGINE=InnoDB 这类操作，**不会自动触发统计更新**——这是线上慢查询最常被忽略的盲点。
持久化开关也得配对开启：innodb_stats_persistent=ON（MySQL 5.6+ 默认开启），否则重启后统计信息全丢，又得重跑 ANALYZE TABLE。
