innodb_sort_buffer_size对建索引无提升作用，因其仅用于批量INSERT时InnoDB内部B+树构建，而ALTER TABLE ADD INDEX走查询层排序路径，依赖sort_buffer_size和read_rnd_buffer_size。
直接说结论：innodb_sort_buffer_size 对大表重建索引时的排序效率基本没有提升作用。它不参与 ALTER TABLE ADD INDEX 的排序过程，也不影响建索引速度。
为什么 innodb_sort_buffer_size 和建索引无关？
这个参数只在 InnoDB 执行批量插入（如 LOAD DATA、INSERT ... SELECT）时构建内部 B+ 树索引的过程中起作用。而常规的 ALTER TABLE ... ADD INDEX 操作走的是另一套路径：
- MySQL 5.6+ 默认优先尝试
ALGORITHM=INPLACE：直接在原表上原地构建索引 B+ 树，不触发排序缓冲区，innodb_sort_buffer_size 完全不生效 - 当 INPLACE 失败（比如字段含 TEXT、BLOB，或日志空间不足），才会 fallback 到“拷表 → 排序 → 写新索引”路径——但此时用的是查询层的
sort_buffer_size和read_rnd_buffer_size，不是引擎层的innodb_sort_buffer_size
真正该调的是哪个 buffer？
如果你观察到建索引卡在 Sorting for index 或 Creating index 状态，且 Sort_merge_passes 显著上升，说明进入了磁盘排序路径。这时起效的是：
-
sort_buffer_size（会话级）：控制排序阶段内存大小，建议设为
8388608（8MB）起手 - read_rnd_buffer_size（会话级）：必须同步设为同量级，避免排序后回表取主键时频繁随机读磁盘
调了 sort_buffer_size 还没变快？检查这三个硬前提
光调缓冲区不够，以下条件缺一不可：
- tmpdir 必须在 SSD 上，且剩余空间 ≥ 表数据大小 × 1.5（排序临时文件可能膨胀）
- 索引字段要有高区分度：对只有 2–3 个值的列（如 status、gender）建索引，再大缓冲也白搭，还拖慢写入
-
确认真的进了排序路径：用
SHOW PROCESSLIST看状态，或对比建索引前后Sort_merge_passes是否猛增
别混淆两个完全不同的 sort buffer
这两个参数名字相似，但运行在不同层级、服务不同场景：
-
sort_buffer_size：SQL 查询层，影响SELECT ... ORDER BY和 fallback 建索引时的排序 -
innodb_sort_buffer_size：InnoDB 引擎层，仅用于INSERT批量写入时的内部索引构建，和ALTER TABLE ADD INDEX无关
配置文件里同时写它们，不会协同加速建索引；改其中一个，对另一个毫无影响。
