MySQL 8.0.27+ 中真正加速二级索引 DDL 的是 innodb_ddl_threads 参数，它控制排序与 B+ 树构建阶段的并发线程数，默认 4，建议设为 CPU 物理核数（如 16），并须同步调大 innodb_ddl_buffer_size（千万级表至少 100MB），而 innodb_parallel_read_threads 对 DDL 无实质影响。
innodb_parallel_read_threads 对 DDL 校验没用
它只影响 SELECT 类查询的全表扫描，不参与任何 DDL 操作。DDL 的 prepare、rebuild、commit 阶段由 InnoDB 存储引擎内部调度，和并行读取线程完全无关。你设 innodb_parallel_read_threads = 16，对 ALTER TABLE ADD INDEX 的执行时间零影响。
真正加速 DDL 的是 innodb_ddl_threads
MySQL 8.0.27+ 才支持 DDL 并行，核心就是这个参数。它控制二级索引创建/重建时的排序与 B+ 树构建阶段的并发线程数：
-
innodb_ddl_threads默认为 4，最大支持 64；建议设为 CPU 物理核数（如 16 核就设 16），但别超 32 —— 多了反而因锁竞争拖慢 - 必须同步调大
innodb_ddl_buffer_size：默认 1MB 太小，线程一多就频繁落盘；实测千万级表至少配 100MB，亿级建议 512MB–1GB -
innodb_parallel_read_threads可配可不配，它只在 DDL 过程中辅助“读取主键数据”阶段，效果远不如前两者直接
为什么你看到的“校验慢”其实不是校验本身
所谓“DDL 校验过程”，常被误指 SHOW PROCESSLIST 里卡在 altering table 的状态。但这其实是 Online DDL 的 prepare 阶段（加 MDL 锁、生成 row log）或 rebuild 阶段（扫描聚簇索引 + 排序建索引），根本不是校验逻辑：
- 长事务阻塞：查
performance_schema.data_lock_waits，看是否有其他事务持TABLE或REC级锁 - I/O 瓶颈：用
iostat -x 1观察%util是否持续 >95%，await在 SSD 上超过 20ms 就说明磁盘扛不住 - change buffer 合并压力大：临时关掉
SET GLOBAL innodb_change_buffering = 'none'，尤其机械盘环境
主键操作永远无法并行，别白费劲
DROP PRIMARY KEY、ADD PRIMARY KEY、REBUILD 全部强制单线程，innodb_ddl_threads 对它们完全无效。这类操作本质是重建整张表，InnoDB 层没有并行路径。真要动主键，优先考虑：
- 是否能用
ALGORITHM=INSTANT绕过？不能 —— 主键变更不在 instant 白名单里 - 是否必须在线？否则用
pt-online-schema-change分摊写入压力，但注意它会双倍占磁盘且拉长主从延迟 - 是否已排除长事务和 I/O 问题？这是比调参更优先排查的点
innodb_ddl_threads 和 innodb_ddl_buffer_size，且只对二级索引有效。其他所有“并行”相关参数，要么不沾边，要么只是配角。 
