ALTER TABLE添加索引卡住或极慢的本质是排序阶段阻塞：当退回到“拷表+排序重建索引”路径时，sort_buffer_size和read_rnd_buffer_size过小导致频繁磁盘I/O；调大二者（如设为8MB）、确保tmpdir在SSD且空间充足，或改用ALGORITHM=COPY, LOCK=NONE可绕过该瓶颈。
ALTER TABLE 添加索引卡住或极慢，本质是排序阶段阻塞
MySQL 在大表上执行 ALTER TABLE ... ADD INDEX 时，如果走的是“原地算法”（如 ALGORITHM=INPLACE）失败，就会退回到“拷表+排序重建索引”路径。这时真正耗时的不是加锁或复制数据，而是对全表数据按索引列排序——这个过程严重依赖 sort_buffer_size 和 read_rnd_buffer_size 的大小。内存不够，就会频繁写临时文件到磁盘，I/O 爆涨，速度断崖式下跌。
调大 sort_buffer_size 能明显提速，但有边界
该参数控制每个线程用于排序的内存缓冲区大小。默认值通常只有 256KB，在千万级表上根本不够用：
- 单次排序无法装入内存 → 触发多路归并，磁盘临时文件数量指数增长
- 增大到 4MB～16MB 常见有效，但超过 32MB 后收益急剧衰减（受
max_sort_length和实际字段长度限制） - 它是会话级变量，只影响当前连接：执行前先
SET SESSION sort_buffer_size = 8388608;（即 8MB） - 不能全局设得过大，否则高并发下易 OOM；专用维护窗口可临时调高，操作完恢复
别忽略 read_rnd_buffer_size 和临时目录 IO
排序后还要回表取数据（比如建二级索引时需读主键值），这部分由 read_rnd_buffer_size 控制。它同样默认偏小（256KB），建议同步调至与 sort_buffer_size 同量级：
SET SESSION read_rnd_buffer_size = 8388608;- 确保 MySQL 临时目录（
tmpdir）所在磁盘是 SSD，且空间充足（排序临时文件可能达表大小的 1.5 倍） - 用
SHOW VARIABLES LIKE 'tmpdir';查路径，避免落在系统盘或满载盘上
更稳的替代方案：用 ALGORITHM=COPY + LOCK=NONE 组合
MySQL 5.6+ 支持在线 DDL，但并非所有情况都自动启用。显式指定可绕过排序瓶颈：
-
ALTER TABLE t ADD INDEX idx_col (col) ALGORITHM=COPY, LOCK=NONE;—— 强制走拷表，但允许并发读写（前提是引擎为 InnoDB、无全文索引等限制） - 此时不依赖排序缓冲区，而是边读原表边构建索引树，内存压力更平缓
- 需确认
innodb_online_alter_log_max_size足够（默认 128MB），否则 DDL 中途因日志溢出失败 - 执行前务必用
SELECT COUNT(*)预估耗时：每百万行约需 30～90 秒（SSD 环境）
真正容易被忽略的是：排序缓冲区调得再大，也救不了索引列本身选择性极差（比如 gender 只有 'M'/'F'）的场景——这种索引本就不该建，强行加只会拖慢写入且几乎不加速查询。
