EXPLAIN的rows离谱大概率因基数统计崩塌，核心依赖采样估算的CARDINALITY（索引列不同值个数），非精确计数；大批量增删、TRUNCATE重灌或数据倾斜致采样失真，需交叉验证rows与实际行数、CARDINALITY与COUNT(DISTINCT)并排除函数/类型转换干扰。
EXPLAIN 的 rows 值离谱，大概率是基数统计崩了
优化器估算扫描行数，核心依赖 CARDINALITY（基数）——它代表索引列中不同值的个数。这个值不是全表扫出来的，而是从约 10–20 个随机索引页采样后推算的。一旦表经历大批量 DELETE + INSERT、TRUNCATE 后重灌、或数据严重倾斜（比如 status 字段 99% 是 'active'），采样结果就和真实分布对不上。
典型表现：EXPLAIN 显示 rows=80000000，但实际只返回 200 行；SHOW INDEX FROM t 中 CARDINALITY 是 2，而 SELECT COUNT(DISTINCT city_id) FROM t 返回 56000。
- 别急着跑
ANALYZE TABLE，先交叉验证这两组数据：预估rowsvs 实际返回行数（差 10 倍以上是强信号）、CARDINALITYvs 真实去重数（差百倍或为 0/1 基本坐实） - 排除干扰：确认没用
WHERE DATE(log_dt) = ...这类函数，也没传错类型（如city_id = '565'字符串查 INT 列） -
CARDINALITY不准 ≠ 索引失效，而是优化器“不信它值得用”——它看到低基数，就默认走全表比回表更省事
ANALYZE TABLE 执行后 EXPLAIN 没变，先查这三件事
ANALYZE TABLE 不是魔法，它只是重新采样并更新 information_schema.STATISTICS 里的字段。执行完发现 EXPLAIN 没换索引，往往不是命令无效，而是优化器根本没“看见”新值，或被更高优先级规则覆盖了。
- 查
SELECT CARDINALITY FROM information_schema.STATISTICS WHERE TABLE_NAME = 't' AND COLUMN_NAME = 'city_id'，确认数值真变了，不只是STATS_INITIALIZED时间戳更新 - 检查 SQL 里有没有
FORCE INDEX或USE INDEX—— 它们会完全绕过优化器，让ANALYZE的努力白费 - 确认没触发更优的覆盖逻辑：比如查询
WHERE a = ? AND b > ?，优化器可能选了idx_a_b而非你期待的idx_a，这不是错，是它判断回表代价更低
innodb_stats_persistent = OFF 是隐形定时炸弹
MySQL 5.7 及以前默认关掉持久化统计，意味着 ANALYZE TABLE 结果只存在内存里。一次重启、一次 SHOW TABLE STATUS、甚至某些元数据操作，都会让统计瞬间回退到过期状态——你昨天刚采样的精准值，今天就又崩了。
- 查当前设置：
SELECT @@innodb_stats_persistent，如果不是ON，请尽快打开：SET GLOBAL innodb_stats_persistent = ON - 开之后，统计落盘，后续自动更新阈值由
innodb_stats_auto_recalc控制（默认开启，变更超 10% 触发） - 若必须保持
OFF，就得把ANALYZE TABLE加入巡检脚本，并监控CARDINALITY波动——偏差超 30% 就自动重采
大表或分区表执行 ANALYZE TABLE 容易卡死或不准
ANALYZE TABLE 对 InnoDB 表加的是表级读锁，期间会阻塞 DROP TABLE、ALTER TABLE 和写入。更麻烦的是，默认采样页数（innodb_stats_persistent_sample_pages = 20）对上亿行或倾斜数据几乎无效。
- 大表务必避开高峰期；线上告警压顶时，宁可先用
FORCE INDEX止血，再择机重采 - 想提高精度，临时调高采样页：
SET GLOBAL innodb_stats_persistent_sample_pages = 100，再执行ANALYZE TABLE t - 分区表默认不分析具体分区，必须显式指定：
ANALYZE TABLE t PARTITION(p2024)，否则只是刷了元数据，没碰真实数据页
EXPLAIN 都见 key 有值，就以为索引还在工作——其实优化器早因 CARDINALITY 崩溃悄悄弃用了它，安静地拖垮性能。 
