mysql 5.7大表加索引默认不锁全表，但切换阶段需短暂mdl_exclusive锁，遇长事务即阻塞；可靠方案为algorithm=inplace, lock=none或pt-online-schema-change，并须验证引擎、row格式、无外键、字段类型等前提条件。
MySQL 5.7 大表加索引默认不锁全表，但会在切换阶段短暂获取 MDL_EXCLUSIVE 锁，只要存在长事务或慢查询，就会卡住 ALTER 并阻塞后续所有读写——这不是“会不会阻塞”，而是“阻塞多久”。真正可控的方案只有两个：显式走 ALGORITHM=INPLACE, LOCK=NONE，或用 pt-online-schema-change。
怎么确认当前表能否走 INPLACE + NONE
别靠经验猜，直接查系统表和变量：
- 先确认引擎和字符集：
SELECT TABLE_NAME, ENGINE, TABLE_COLLATION FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table';—— 必须是InnoDB - 再查关键参数：
SELECT @@version, @@binlog_format, @@innodb_file_per_table;——binlog_format必须为ROW，innodb_file_per_table必须为ON - 检查外键：
SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table' AND CONSTRAINT_NAME LIKE 'fk%';—— 有外键就直接退化为COPY - 检查字段类型：不能对
TEXT/BLOB列建索引而不指定前缀，例如ADD INDEX idx_content (content(255))合法，ADD INDEX idx_content (content)会失败
为什么显式指定 ALGORITHM=COPY, LOCK=NONE 反而更稳
当 INPLACE 不满足前提时，硬上只会触发全表拷贝+排序重建，而 ALGORITHM=COPY, LOCK=NONE 是 MySQL 5.7 明确支持的“允许并发读写”的拷表路径（前提是 InnoDB 表、无全文索引等）：
- 它不依赖
sort_buffer_size，绕过排序瓶颈；内存压力更平缓，不会因缓冲区小导致磁盘临时文件爆炸 - 需确保
innodb_online_alter_log_max_size足够大（默认 128MB），否则 DDL 中途可能因日志溢出失败 - 执行前建议临时调大：
SET SESSION sort_buffer_size = 8388608; SET SESSION read_rnd_buffer_size = 8388608;—— 即使走 COPY，这两个参数也影响回表构建索引的效率 -
tmpdir必须指向 SSD 且空间充足（临时文件可达表大小的 1.5 倍）
加唯一索引前必须清理重复数据
唯一索引创建失败几乎全是已有重复值导致，MySQL 不会提示具体哪行冲突，只报 ERROR 1062 (23000): Duplicate entry 'xxx' for key 'uk_col'：
- 先查重：
SELECT col, COUNT(*) FROM my_table GROUP BY col HAVING COUNT(*) > 1; - 注意 NULL 值：InnoDB 允许多个
NULL，但业务上是否合理需人工判断 - 清理示例（保留最大
id）：DELETE t1 FROM my_table t1 INNER JOIN my_table t2 WHERE t1.id - 清理后务必在从库或备份库验证逻辑，避免误删
- 加索引语句必须显式写全：
ALTER TABLE my_table ADD UNIQUE KEY uk_email (email) ALGORITHM=INPLACE, LOCK=NONE;
pt-osc 执行慢时优先调哪些参数
108GB 表用 pt-online-schema-change 跑 N 小时，问题通常不在工具本身，而在默认参数没适配大表 IO 特性：
-
--chunk-size=10000：太小会导致频繁切块、大量 round-trip，增大到50000～100000可显著减少切换次数 -
--max-load Threads_running=50：阈值设太低会频繁暂停；若业务负载稳定，可放宽到100～200 -
--set-vars 'wait_timeout=10000 innodb_lock_wait_timeout=60'：避免网络抖动或短时锁等待导致重试失败 -
--recursion-method=none：禁用从库探测，避免因主从延迟误判 - 务必加
--print预览 SQL，确认生成的中间表名、触发器逻辑无误
真正容易被忽略的是：索引列选择性极差（比如 gender 只有 'M'/'F'）时，哪怕加索引成功，也救不了查询性能，反而拖慢写入——这种索引不该建，而不是研究怎么加得快。
