innodb_parallel_read_threads 不加速索引重建，因其仅用于SELECT全表扫描；真正提速二级索引创建的是 innodb_ddl_threads（8.0.27+），控制DDL排序阶段并发线程数，需配合 innodb_ddl_buffer_size 调优并满足前提条件。
并行扫描（innodb_parallel_read_threads）本身不参与索引重建，它只加速满足苛刻条件的 SELECT 全表扫描；真正能提速索引重建的是并行 DDL（innodb_ddl_threads），且仅对二级索引生效。
为什么 SET innodb_parallel_read_threads 没法加快建索引
这个参数控制的是查询执行层的并行扫描，而 ALTER TABLE ADD INDEX 是 DDL 操作，走的是 InnoDB 的 DDL 子系统，两者路径完全隔离。即使你设了 innodb_parallel_read_threads = 16，建索引过程里也完全不会调用它。
-
EXPLAIN FORMAT=TREE输出里出现Parallel scan，只说明某条SELECT语句启用了并行——和建索引无关 - 建索引时若走
ALGORITHM=INPLACE（默认行为），整个流程在原表上增量构建 B+ 树，不依赖主键扫描，自然也不触发并行读 - 只有 fallback 到“拷表+排序”路径（即
ALGORITHM=COPY）时，才需要全表扫描主键，但此时用的也不是innodb_parallel_read_threads，而是内部排序线程池，由innodb_ddl_threads控制
真正起效的是 innodb_ddl_threads（MySQL 8.0.27+）
这是唯一能直接加速二级索引创建的并行参数。它控制排序阶段的并发线程数，对大表建索引的耗时影响显著，但有硬性前提：
- 必须是 MySQL 8.0.27 或更高版本；老版本靠
innodb_sort_buffer_size+ 线程调度隐式并行，不可控 - 只对二级索引有效：主键重建（如
ALTER TABLE ... ENGINE=InnoDB）仍是单线程 - 需显式开启：默认值为
1，必须设为>1才可能触发多线程，例如SET GLOBAL innodb_ddl_threads = 4 - 别忽略内存配比：增大该值时，应同步检查
innodb_ddl_buffer_size是否足够，否则线程争抢 buffer 导致归并频繁落盘
迁移后重建索引的实操组合策略
大表迁移后重建索引，不能只靠一个参数。关键是在数据导入完成、建索引前做三件事：
- 先关掉干扰项：
SET unique_checks = 0和SET foreign_key_checks = 0（如果确认数据合规） - 调高并行能力：
SET GLOBAL innodb_ddl_threads = 4（SSD 环境下，16 核机器可试 8） - 确保缓冲够用：
SET GLOBAL innodb_ddl_buffer_size = 268435456（256MB，按线程数均分后每线程约 64MB） - 统一建索引：
ALTER TABLE t ADD INDEX idx_a (a), ADD INDEX idx_b (b)，避免多次 DDL 触发重复扫描
注意：这些设置对已存在的连接无效，新连接或 FLUSH PRIVILEGES 后新建会话才生效；且 innodb_ddl_threads 是全局动态变量，无需重启。
最容易被忽略的降级点
即使你设了 innodb_ddl_threads = 8，建索引仍可能静默退回到单线程——不是参数没生效，而是条件不满足：
- 索引字段选择性极低（如
status ENUM('on','off')），优化器判断并行归并代价高于单线程排序，直接放弃 - 临时目录
tmpdir在机械盘或空间不足，导致排序无法使用内存 buffer，被迫降级为磁盘归并 - 表上有未提交的长事务，阻塞了 DDL 的 prepare 阶段，
SHOW PROCESSLIST显示altering table却不动，实际卡在锁等待 - 字符集或 collation 在迁移中被意外修改（如从
utf8mb4_0900_as_cs变成utf8mb4_general_ci），导致索引字段比较逻辑异常，DDL 内部报错 fallback
验证是否真并行：建索引过程中查 performance_schema.threads，过滤 NAME LIKE '%ddl%'，看活跃线程数是否接近你设的 innodb_ddl_threads 值——这是比看文档更可靠的依据。
