sort_buffer_size影响建索引速度，因其控制排序过程的内存缓冲：过小导致频繁磁盘归并、I/O激增；过大引发内存压力甚至OOM；合理设置（如千万级表调至2MB–16MB）可显著加速B-tree索引构建。
为什么 sort_buffer_size 会影响建索引速度
MySQL 在创建索引（尤其是 ALTER TABLE ... ADD INDEX 或 CREATE INDEX）时，若使用的是排序算法（如 filesort），会把待排序的键值先缓存在内存里。这个缓存大小就由 sort_buffer_size 控制。它不是全局共享的，而是每个线程独占一份——也就是说，并发建索引时，总内存消耗是线程数 × 该值。
如果设得太小，MySQL 会频繁地把中间结果写到磁盘临时文件，再归并，I/O 暴增，建索引时间可能翻几倍；设得太大，又容易触发 OS 级别的内存压力，甚至被 OOM killer 干掉。
常见错误现象：Creating index 状态卡住几十秒、ALTER TABLE 执行时间远超预期、SHOW PROCESSLIST 显示大量 Sorting for table 状态。
-
sort_buffer_size默认值通常只有 256KB（MySQL 8.0），对百万级以上表建索引基本不够用 - 它只影响「需要排序」的索引构建场景，比如普通 B-tree 索引；对全文索引、空间索引或使用
ALGORITHM=INPLACE的部分操作不生效 - 该参数是会话级的，
SET SESSION sort_buffer_size = 10485760只对当前连接有效，不影响其他连接 - 线上调大前务必确认剩余物理内存：单次建索引若用 32MB 缓冲，5 个并发就是 160MB，别和
innodb_buffer_pool_size抢内存
怎么安全地调高 sort_buffer_size 加速建索引
不是越大越好，关键是在“避免落盘”和“不挤占核心内存”之间找平衡点。实测中，对千万行表，2MB～16MB 是较稳妥的区间。
使用场景：批量导入后补索引、历史表结构变更、离线数据处理任务。
推荐做法：
- 先查当前值：
SELECT @@sort_buffer_size（单位字节） - 建索引前显式设置：
SET SESSION sort_buffer_size = 8388608（即 8MB） - 配合
ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE（如支持）减少锁等待，但注意：INPLACE 不等于不排序，某些列类型变更仍需排序 - 不要在
my.cnf里全局调高，否则所有连接都分配大缓冲，空闲连接也占内存 - 建完立刻恢复默认（可选）：
SET SESSION sort_buffer_size = DEFAULT
示例对比（千万行表）：
SET SESSION sort_buffer_size = 262144; -- 默认值 ALTER TABLE orders ADD INDEX idx_user_id (user_id); -- 耗时约 210 秒 <p>SET SESSION sort_buffer_size = 8388608; -- 8MB ALTER TABLE orders ADD INDEX idx_user_id (user_id); -- 耗时约 42 秒
sort_buffer_size 和其他排序相关参数的关系
它只是排序链路中的一环，单独调它效果有限，容易忽略的是协同参数：
-
read_rnd_buffer_size：影响排序后回表读取行数据的效率，建二级索引时也会参与，建议与sort_buffer_size同量级（如都设为 8MB） -
tmp_table_size和max_heap_table_size：控制内部临时表内存上限，若排序过程中生成临时表（如涉及 GROUP BY + ORDER BY），这两个值不够也会被迫落盘 -
innodb_sort_buffer_size（仅 MySQL 8.0+）：InnoDB 专用排序缓冲，用于CREATE INDEX的内部排序，独立于sort_buffer_size，默认 1MB，可按需调至 4MB～16MB - 注意：这些参数之间无自动联动，必须手动配平，否则会出现“调了 A 没用，因为 B 先卡住了”的情况
真正决定建索引速度的，往往不是缓冲大小
很多人花半天调参，最后发现瓶颈其实在 I/O 或锁上。几个更常被忽略的硬性限制：
- 磁盘随机写性能：SSD 和 HDD 建索引耗时可能差 5 倍以上，
iostat -x 1看%util和await是否持续高位 - 唯一索引校验开销：建
UNIQUE索引时，MySQL 必须逐行检查重复，无法绕过，缓冲再大也没用 - 并发度陷阱：盲目开多个
ALTER TABLE并发，反而因争抢 I/O 和 CPU 导致总体更慢 - 表碎片率高：
OPTIMIZE TABLE或ALTER TABLE ... ENGINE=InnoDB重建表后建索引，速度常提升明显
缓冲参数只是“加速器”，不是“发动机”。真要压时间，优先看磁盘、看唯一性、看是否能分批建索引，再动 sort_buffer_size。
