MySQL 8.0 提供的并行扫描特性，首先需要明确的是，它并不能直接提升备份过程的执行速度——然而，在备份完成后的某些数据校验场景中，却能带来显著的性能提升，前提是这些校验操作恰好满足并行扫描的触发条件。具体而言，只有 COUNT(*)、CHECK TABLE（第二次扫描）以及那些无索引、无 LIMIT 的 SELECT 查询才有可能触发并行机制，并且必须通过 EXPLAIN FORMAT=TREE 来确认是否真正生效。此外，innodb_parallel_read_threads 配置参数、表结构设计、事务隔离级别等硬性约束只要有一个不达标，并行扫描就形同虚设。
哪些校验操作能真正利用并行扫描？
实际上，只有极少数校验类型的语句在 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 来捕获真实行为。说到底，并行扫描是一把好刀，但使用之前必须先确认刀刃确实在手上。
