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 抓真实行为。
