MySQL 8.0并行查询索引统计不准确解决方案

先纠正一个常见的误解

很多人以为MySQL 8.0支持“并行查询”，其实MySQL 8.0本身并不支持像PostgreSQL的parallel seq scan或Oracle的PQ那样的真正并行查询。所谓“并行”在MySQL里，通常指的是客户端并发执行多个查询，或者通过分区表、分库分表人工拆分。真正影响索引统计信息准确性的，不是“并行查询”本身，而是高并发写入加上统计采样机制的固有缺陷。解决问题的方向，必须落在统计信息更新策略和直方图上，而不是去“配置并行查询参数”——因为MySQL根本不存在这个开关。

为什么ANALYZE TABLE在高并发写入后常失效

当大批量INSERT/UPDATE/DELETE持续发生时，ANALYZE TABLE容易踩中两个硬伤：

• 它依赖当前事务快照读取数据页，若存在长事务（尤其是未提交的UPDATE），InnoDB可能卡在构建一致性视图阶段，导致采样中断或退化为极少量页（甚至只采1–2页），CARDINALITY估算直接归零或严重失真
• 即使命令返回OK，也不代表统计已持久化：若innodb_stats_persistent = OFF（MySQL 5.7默认关，8.0+默认开，但旧实例升级后可能仍关），统计仅存内存，下次重启或后台自动更新触发后立即回退
• 默认采样页数innodb_stats_persistent_sample_pages = 20对千万级以上表完全不够——20个页可能全落在同一数据段（例如status=1占99%的场景），导致优化器误判选择率

直方图是比ANALYZE TABLE更稳的补救手段

对已知分布不均的列（如status、region_id、user_type），ANALYZE TABLE很难救回来，而直方图能绕过采样缺陷，直接记录实际分布：

• 必须用CREATE STATISTICS显式创建，例如：

  CREATE STATISTICS s_status ON t (status) AS 'equi-height';

  （MySQL 8.0.19+支持，类型选equi-height更适合倾斜数据）
• 直方图不依赖采样页数，而是扫描实际数据并分桶；只要建好，后续优化器会优先用它估算WHERE status = 'paid'这类条件的行数
• 注意：直方图不会自动更新，数据剧烈变动后需手动重建（DROP STATISTICS + CREATE STATISTICS），不能指望它“自适应”

关键参数必须检查并固化

很多线上实例仍沿用老配置，导致统计行为不可控：

• 确认innodb_stats_persistent = ON：否则所有ANALYZE TABLE都是临时工，查SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'innodb_stats_persistent';
• 调高采样页数不是“越大越好”，建议按表规模分级设置：
  – 百万行以下：保持默认20
  – 千万行：设为50–100
  – 亿级：设为200（上限受innodb_buffer_pool_size影响，避免OOM）
  执行：

  SET GLOBAL innodb_stats_persistent_sample_pages = 100;

• 关闭innodb_stats_on_metadata = OFF（MySQL 8.0默认已是OFF，但要确认）：防止SHOW TABLE STATUS触发意外分析，干扰业务稳定性

分区表ANALYZE必须指定PARTITION

对按时间或地区分区的大表，ANALYZE TABLE t默认只更新元数据，完全不触碰任何分区的数据页，CARDINALITY会维持为0或旧值：

• 必须明确指定分区：

  ANALYZE TABLE t PARTITION(p202405);

• 若需全量更新，得写脚本循环所有分区，或改用ANALYZE TABLE t ALL PARTITIONS（MySQL 8.0.23+ 支持）
• 直方图也需按分区单独建：CREATE STATISTICS s_col ON t PARTITION(p202405) (col)，跨分区直方图不生效

最后，也是最容易被忽略的一点：统计信息不准的根因往往不在“怎么分析”，而在“谁在写”。如果业务端持续跑着未提交的大事务、或凌晨ETL脚本长期持有锁，ANALYZE TABLE和直方图都会失效——先盯住INFORMATION_SCHEMA.INNODB_TRX查长事务，再动手修统计。