MySQL 5.6+ 对普通二级索引 ADD INDEX 默认使用 Online DDL，不锁表但需满足严格前提：InnoDB 引擎、非唯一索引、无长事务持有 MDL，否则降级为 COPY 算法全程锁表。
MySQL 5.6+ 直接 ADD INDEX 会锁表吗？
在 MySQL 5.6 及以上版本，对普通二级索引执行 ALTER TABLE ... ADD INDEX 默认启用 Online DDL（前提是未显式指定 ALGORITHM=INPLACE 或 ALGORITHM=COPY），但「不锁表」是有严格前提的：
- 必须是二级索引（非主键、非唯一约束校验触发的索引）
- 表引擎为
InnoDB - 未开启
old_alter_table=ON - DDL 过程中不能有长事务或未提交的 DML 持有元数据锁（MDL）
一旦不满足条件（比如加的是唯一索引、或同时修改列定义），MySQL 会自动降级为 COPY 算法，全程锁表（WRITE 锁），阻塞所有 DML。线上大表极易因此触发超时或业务中断。
pt-online-schema-change 是怎么绕过锁表的？
pt-osc 不依赖 MySQL 内部 DDL 机制，而是用“影子表 + 触发器 + 增量拷贝”模拟在线变更。它真正规避的是 ALTER 阶段的锁，但仍有关键约束：
- 原表必须有主键或唯一非空索引（否则无法准确定位增量行）
- 不能存在同名触发器（
pt-osc会创建自己的INSERT/UPDATE/DELETE触发器） - 复制延迟过高时，
--chunk-size和--max-lag设置不当会导致拷贝卡住或主从不一致 - 触发器本身会轻微增加写入延迟，高并发写场景需压测验证
典型命令：
pt-online-schema-change --alter "ADD INDEX idx_status_created(status,created_at)" D=mydb,t=my_large_table --execute
Online DDL 和 pt-osc 性能与风险对比
两者不是互斥替代，而是适用场景不同：
-
ALGORITHM=INPLACE（Online DDL）：快、资源省，但失败概率随表大小和索引复杂度上升；加索引期间仍需持有MDL_SHARED_UPGRADABLE锁，可能被长查询阻塞 -
pt-osc：更可控、可中断、支持限流（--max-load,--critical-load），但总耗时更长，占用双倍磁盘空间，且触发器在极端情况下可能丢失变更（如主库 crash 后从库回放触发器失败） - MySQL 8.0 的
INSTANT算法仅支持加列（不含索引）、改列名等极轻量操作，对加索引无效
线上大表加索引前必须检查的三件事
跳过任何一项都可能导致变更失败或雪崩：
- 确认当前
innodb_lock_wait_timeout和应用侧超时是否匹配（pt-osc默认等待 1 秒锁，太短易重试风暴） - 用
SELECT COUNT(*)+EXPLAIN FORMAT=JSON验证目标索引字段的选择性——低选择性索引（如status TINYINT）不仅无效，还拖慢写入 - 检查
information_schema.INNODB_TRX和PROCESSLIST，确保无运行超 30 秒的事务；否则pt-osc创建触发器或 Online DDL 获取 MDL 时会卡死
真正危险的不是工具选错，而是把“不锁表”当成绝对保证——只要还有未提交事务、主从延迟、或磁盘 I/O 打满，任何方案都会暴露本质：索引构建本身就是 I/O 与 CPU 密集型操作，只能调度，无法消除代价。
