怎样利用MySQL 8.0的并行扫描特性加速备份校验？

MySQL 8.0并行扫描不能加速备份本身，仅能提升满足条件的校验查询速度：仅COUNT()、CHECK TABLE（第二次扫描）、无索引无LIMIT的SELECT 可能触发并行；需EXPLAIN FORMAT=TREE验证，且受innodb_parallel_read_threads配置、表结构、事务隔离级别等多重硬性限制。

MySQL 8.0 的并行扫描特性**不能直接用于加速备份本身**，但它能显著提升备份后对大表的校验类查询（如 COUNT(*)、CHECK TABLE）速度——前提是这些校验操作恰好满足并行扫描的硬性触发条件。

哪些校验操作真能用上并行扫描？

只有极少数校验类语句在 InnoDB 层走全表物理扫描时，才可能启用并行：

• COUNT(*) FROM huge_table：无 WHERE、无 GROUP BY、表是普通 InnoDB 表、且未命中覆盖索引时，innodb_parallel_read_threads > 0 才可能生效
• CHECK TABLE huge_table：该语句会扫描主键索引两次，**第二次扫描**明确支持并行（官方文档确认）
• SELECT * FROM huge_table（用于人工抽样比对）：仅当无索引可用、无 LIMIT、无 ORDER BY，且数据量足够大（通常 > 百万行）时，EXPLAIN FORMAT=TREE 才显示 Parallel scan on huge_table

不支持的场景包括：COUNT(id)（非 *）、带 LIMIT 的校验、任何含 WHERE 条件的过滤校验、分区表或 MyISAM 表上的校验。

为什么 SET innodb_parallel_read_threads=4 后校验还是慢？

参数设了≠就生效。常见静默失效原因：

• 执行前没用 EXPLAIN FORMAT=TREE SELECT COUNT(*) FROM huge_table 验证——普通 EXPLAIN 或 EXPLAIN FORMAT=JSON 完全不显示并行信息
• 表上有 status 索引，而你执行的是 COUNT(*) WHERE status = 'ERROR'：优化器走索引查找，绕过全表扫描路径
• 查询被重写成派生表（例如嵌套在 SELECT ... FROM (SELECT ...) AS t 中），导致并行节点被包裹在内层，无法作为最外层扫描启用
• 系统 buffer pool 已缓存整张表，InnoDB 认为“无需并行读磁盘”，直接从内存拉取，此时参数无效

怎么安全配置并行线程数做校验？

这个参数是会话级的，值过大反而拖慢校验速度：

• SSD 环境：从 SET SESSION innodb_parallel_read_threads = 4 开始测试；若 CPU 核心数 ≥ 16，可试到 8–12；超过 16 基本无收益，还可能触发 InnoDB: Warning: parallel read threads exceed available CPU
• HDD 环境：设 2–4 即可，再多线程争抢磁头，随机寻道延迟上升
• 生产环境需长期生效，必须写入 my.cnf 的 [mysqld] 段：innodb_parallel_read_threads = 4；SET GLOBAL 对已连接会话无效

注意：innodb_parallel_read_threads 控制的是“单次查询最多可用的后台扫描线程数”，不是全局线程池。一次 CHECK TABLE 和一次 COUNT(*) 是各自独立调度的。

如何确认并行真的在跑校验？

光看执行时间快了不行，得验证是否真正分发了多线程：

• 用 EXPLAIN ANALYZE SELECT COUNT(*) FROM huge_table，搜索输出中是否有 "parallel_workers": N（N > 1）和 "rows_examined_per_worker" 字段，且各 worker 行数接近总行数 / N
• 查 performance_schema.threads：执行校验时运行 SELECT THREAD_ID, PROCESSLIST_INFO FROM performance_schema.threads WHERE PROCESSLIST_INFO LIKE '%COUNT(*)%'，应看到多个 query exec 类型线程（不止一个）
• 对比指标：并行启用后，Innodb_rows_read 增速应明显高于 Handler_read_rnd_next，说明数据读取被分摊到了多个线程

最容易被忽略的一点：即使 EXPLAIN FORMAT=TREE 显示了 Parallel scan，只要校验过程中发生 gap lock 冲突（比如事务隔离级别为 REPEATABLE READ 且有其他长事务），InnoDB 仍可能在执行阶段静默降级为单线程扫描——此时只能靠 EXPLAIN ANALYZE 或 performance_schema 抓真实行为。