结论先行：EXPLAIN 的
rows列不是「这条 SQL 要扫多少行」，而是 InnoDB 用「采样页估算的基数」除以「等值条件值个数」算出来的一个期望值。当数据分布严重倾斜、且你那个「头部值」恰好落在没被采样的页里时，rows会把一个命中 1800 万行的大客户估成 120 行——优化器基于这个数字选了二级索引 + 回表，结果回表 1800 万次，P99 从 6ms 飙到 4.2s。这类「EXPLAIN 看着很完美、实际很慢」的案子，根因几乎都在统计信息，而不是索引本身。这篇把机制、验证、校正一次讲清。
一、现象：rows=120，实际扫了 1800 万行
去年给一套理财中台做慢查询巡检。核心表 t_user_asset：1.2 亿行、单表 96GB、InnoDB、MySQL 8.0.32，innodb_stats_persistent=ON（8.0 默认）。业务方甩来一条「很普通」的查询：
SELECT asset_id, amount, status
FROM t_user_asset
WHERE user_id = 888123
AND asset_type = 2;
EXPLAIN 输出：
type=ref, key=idx_user_asset_type, key_len=9, ref=const,const, rows=120, Extra=Using index condition
type=ref、rows=120、走了联合索引——按常规经验这应该是一条 5ms 以内的查询。但 EXPLAIN ANALYZE（8.0）给出的实际是：
rows examined：18,034,211（1800 万）loops=1，actual time=4213.7..4214.1 us- P99 一周窗口：4.2s，而同一 SQL 换一个小用户
user_id只要 6ms
差异 700 倍，全落在 user_id 这一个值上。user_id=888123 是一个机构级大客户，名下资产占全表约 15%（≈1800 万行）；而 EXPLAIN 把它估成了 120 行。
二、根因：InnoDB 统计信息只采样 20 页，头部数据被漏采
关键机制在 innodb_stats_persistent_sample_pages，默认值是 20。它的意思是：ANALYZE TABLE 时，InnoDB 对每个索引随机抽 20 个叶子页，统计这 20 页里「每个不同值大概占多少」，再外推到整表。它不扫全表（这是为了大表 ANALYZE 不锁太久）。
问题就出在「随机抽 20 页」上：
- 1.2 亿行表，
idx_user_asset_type有上百万个叶子页，随机抽 20 页，命中「头部大客户 888123 的页」的概率极低——因为 InnoDB 按主键顺序聚簇，某个 user_id 的数据集中在一片连续区间，20 页随机抽样大概率整段跳过它。 - 抽样没覆盖到这个值，优化器就用「平均基数」兜底。1.2 亿行 ÷ 约 100 万个不同 user_id ≈ 120——
rows=120就是这么来的，它代表的是「一个普通 user_id 的平均资产数」，而不是 888123 的真实行数。 - 于是优化器算成本：
ref访问 120 行 + 回表，成本模型认为这比全表扫 1.2 亿行便宜 1000 倍，果断选二级索引。实际执行时这个 user_id 命中 1800 万行，回表 1800 万次随机 I/O，成本模型从一开始就基于错误输入。
一句话：rows 是「期望值」不是「实际值」，分布倾斜 + 采样漏采，会让期望值和实际值差出几百到几千倍。
补充一个反直觉点：innodb_stats_auto_recalc 默认 ON，innodb_stats_auto_recalc_threshold 默认 10%（DML 变动超 10% 行就自动重算）——但它重算时还是只采样 20 页，所以「自动重算」并不能救倾斜场景，只是让统计信息「新鲜」，不是「准确」。
三、具体做法：先验证、再校正
1. 验证真实扫描行数，别信 EXPLAIN 的 rows
-- 8.0 首选：真实执行 + 真实行数
EXPLAIN ANALYZE
SELECT asset_id, amount, status
FROM t_user_asset
WHERE user_id = 888123 AND asset_type = 2;
-- 通用：执行前后对比 Handler 计数，最硬
FLUSH STATUS;
SELECT asset_id, amount, status FROM t_user_asset
WHERE user_id = 888123 AND asset_type = 2;
SHOW SESSION STATUS LIKE 'Handler_read%';
-- Handler_read_rnd_next / Handler_read_key 增量 ≈ 真实回表次数
如果 Handler_read_key 增量是千万级、而 EXPLAIN rows=120，基本可以断定是统计信息失真。
2. 校正一：强制刷新 + 提高采样页数
-- 临时把采样页数调大（需要重 ANALYZE 才生效，注意大表 ANALYZE 耗时）
SET GLOBAL innodb_stats_persistent_sample_pages = 200;
ANALYZE TABLE t_user_asset;
注意：sample_pages 调大只是提高命中率，对极端头部值（占 15%）仍可能漏。大表 ANALYZE 本身有成本，1.2 亿行 + 96GB 我实测一次约 40~70s，且期间会短暂持有 MDL 共享锁，生产建议在低峰做，别在 DML 高峰裸跑。
3. 校正二（对倾斜最有效）：8.0 直方图
-- 给倾斜列建直方图，优化器能拿到真实分布
ALTER TABLE t_user_asset
ALTER COLUMN user_id ADD STATS_HISTOGRAM '{"number-buckets": 256, "null-value": false}';
SELECT COLUMN_NAME, JSON_EXTRACT(HISTOGRAM,'$.histogram.json')
FROM INFORMATION_SCHEMA.COLUMN_STATISTICS
WHERE TABLE_NAME='t_user_asset' AND COLUMN_NAME='user_id';
直方图是分桶统计，能显式记录「888123 这一档占 15%」，比 20 页采样对头部值友好得多。我建完 256 桶直方图后，EXPLAIN rows 对 user_id=888123 估到了 1.7 千万（接近真实 1800 万），优化器改判后这条查询走了「直接按 user_id 范围扫聚簇索引」而不是回表，P99 从 4.2s 降到 380ms（因为 1800 万行本身就是要扫的，380ms 是扫 15% 数据的合理下限，不是 6ms）。
4. 校正三（兜底）：对已知头部值用 FORCE INDEX 或改写
-- 对确认是大客户的 user_id，强制走更合适的路径
SELECT asset_id, amount, status
FROM t_user_asset FORCE INDEX(PRIMARY)
WHERE user_id = 888123 AND asset_type = 2;
或把「大客户的列表查询」拆到读模型/离线宽表，别让它和长尾小客户共用一条 SQL——这在数据倾斜场景往往是更稳的工程解。
四、踩过的坑 / 反直觉之处
ANALYZE TABLE不是万能药：默认 20 页采样对「均匀分布」够用，对「头部倾斜」基本无效。我第一版就是反复 ANALYZE，rows 一直是 120，白忙活，直到上直方图才解决。- 别拿
type=ref当「快」的判据：ref只是访问类型好看，rows失真时ref反而是最贵的路径（海量回表）。判断快慢要看Handler_read*或EXPLAIN ANALYZE的rows examined。 - 直方图有内存和基数代价：
COLUMN_STATISTICS的直方图存在内存里，对超大基数列（如 UUID 级 distinct）建直方图意义不大且占内存；它最适合「基数中等 + 分布倾斜」的列（user_id、status、region 这类）。 rows估「偏小」和「偏大」都危险：估小（本例）→ 错选回表；估大 → 优化器放弃明明该用的索引、走全表。两种都要靠真实行数验证来识别，不能只看「rows 小是不是就快」。- 倾斜是动态的：新大客户进来、某 user_id 资产暴涨，rows 又会失真。建议把「EXPLAIN rows 与 EXPLAIN ANALYZE rows 偏差 > 10 倍」纳入慢查询巡检的自动告警项，而不是等 P99 爆了才查。
五、结论与可复用清单
EXPLAIN rows是「采样基数外推的期望值」，不是实际扫描行数；分布倾斜 +innodb_stats_persistent_sample_pages（默认 20）漏采，是「rows 骗人」的主因。- 验证口径：
EXPLAIN ANALYZE的rows examined或Handler_read_key/rnd_next增量，才是真实成本。 - 校正优先级：倾斜列建
STATS_HISTOGRAM（最有效）→ 调大sample_pages后ANALYZE（治标）→ 已知头部值FORCE INDEX/ 拆读模型（兜底）。 - 别把
type=ref当快，也别迷信「自动重算」——它只是让统计信息新鲜，不是准确。 - 把「rows 估算 vs 实际偏差 > 10 倍」写进巡检告警，倾斜场景会随业务增长复发。
参考：站内「慢查询治理三件套」（EXPLAIN 的 rows 是估算值，别当精确数字）与「低基数字段选择性分析」（ref 好看 ≠ 总成本低）两篇，本文把「为什么 rows 会失真」这一层补上。