mysql生产环境加索引优先用algorithm=inplace的online ddl；大表或需强一致性时才选pt-osc，且加唯一索引前必须查重并清理重复数据。
MySQL 生产环境在线加索引，优先用 ALGORITHM=INPLACE 的 Online DDL；大表或需强一致性校验时，才考虑 pt-online-schema-change（pt-osc）。
MySQL 5.6+ 默认支持 Online DDL 加索引，但不是所有操作都真正“无锁”
从 MySQL 5.6 开始，ALTER TABLE ... ADD INDEX 默认走 INPLACE 算法（前提是引擎为 InnoDB，且不涉及列类型变更等限制）。它在 Execute 阶段不持有 MDL 写锁，因此 DML（INSERT/UPDATE/DELETE）可正常执行。
但要注意三个关键点：
-
Prepare和Commit阶段仍需短暂获取 MDL 锁 —— 若此时有长事务或大查询阻塞了 MDL，整个加索引会被卡住，表现为Waiting for table metadata lock - 全量扫描主键索引构建新索引的过程，会显著增加 I/O 和 CPU 压力，可能拖慢从库同步（尤其大表）
- 唯一索引会全程校验重复值，一旦发现冲突直接报错：
Duplicate entry 'xxx' for key 'uk_col'，不会跳过
验证是否启用 Online DDL：执行前加 ALGORITHM=INPLACE, LOCK=NONE 显式声明（MySQL 5.6.17+ 支持），例如：
ALTER TABLE orders ADD UNIQUE INDEX uk_order_no (order_no) ALGORITHM=INPLACE, LOCK=NONE;
pt-osc 适合大表、需规避主从延迟、或无法停写但允许数据覆盖的场景
pt-online-schema-change 不依赖 MySQL 原生 Online DDL，而是通过触发器双写实现“无锁”，但它本质是数据迁移，行为与原生 DDL 有根本差异：
- 不校验全量数据唯一性：全量拷贝用
INSERT IGNORE，遇到重复直接丢弃；增量用REPLACE INTO或DELETE + REPLACE，相当于“后写覆盖” - 触发器带来额外开销：每个 DML 都要触发一次额外 SQL，高并发下可能放大延迟
- 磁盘空间翻倍：需同时存原表 + 新表 + 触发器日志临时表
- 不兼容某些场景：如表含外键、全文索引、虚拟列，或已存在同名触发器时会失败
典型使用命令（加唯一索引）：
pt-online-schema-change \ --alter "ADD UNIQUE INDEX uk_user_email (email)" \ --execute \ D=test,t=users \ --chunk-size=1000 \ --max-load="Threads_running=25" \ --critical-load="Threads_running=50"
其中 --chunk-size 控制每次迁移行数，--max-load 是防雪崩的熔断阈值。
加唯一索引前必须检查重复数据，否则 Online DDL 直接失败
Online DDL 对唯一索引的校验是强一致的，只要有一条重复记录，整个语句回滚，不留下部分索引。而 pt-osc 会静默丢弃或覆盖 —— 这不是“成功”，是数据丢失。
务必先查重：
SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1;
若发现重复，必须人工决策处理方式：
- 业务允许去重？用
DELETE或UPDATE清理 - 业务要求保留？说明该字段本就不该建唯一索引
- 临时加索引仅用于查询加速？改用普通索引
ADD INDEX idx_email (email)
别指望 IGNORE 或 IF NOT EXISTS 躲过校验 —— 唯一索引不支持这些修饰符。
线上加索引最易被忽略的三件事
第一，没看从库状态就执行：主库加索引快，但从库单线程回放 DDL 可能卡住，导致复制延迟飙升甚至中断。务必确认 Seconds_Behind_Master 接近 0，且无长事务。
第二，误判“低峰期”：所谓低峰不等于无流量，而是指无大事务、无批量导入、无报表类慢查询。一个未提交的 SELECT ... FOR UPDATE 就能让 Online DDL 卡死。
第三，没预留足够磁盘空间：Online DDL 加索引期间，临时索引文件 + undo log + buffer pool 压力可能让磁盘使用率瞬间拉满。建议空闲空间 ≥ 表大小的 1.5 倍。
