MySQL 5.6前ALTER TABLE ADD INDEX全程锁表，5.6+支持ALGORITHM=INPLACE但非完全免锁，仍可能因唯一索引、外键等退化为copy模式，且DDL起止需短暂MDL_WRITE锁。
ALTER TABLE ADD INDEX 会锁表吗？
MySQL 5.6 之前，ALTER TABLE ADD INDEX 默认全程锁表（copy table 方式），DML 阻塞，线上服务直接卡死。5.6 起支持 ALGORITHM=INPLACE，但不是所有情况都免锁——比如给大表加唯一索引、或在有外键的列上建索引时，仍可能退化为 copy 模式。
常见错误现象：SHOW PROCESSLIST 里看到状态是 altering table，同时 INSERT/UPDATE 请求大量超时或堆积；监控发现 Threads_running 突增、Innodb_row_lock_waits 上升。
- 确认是否真正支持 online DDL：执行
SELECT VERSION()，确保 ≥ 5.6，再查INFORMATION_SCHEMA.INNODB_TRX看是否有长事务阻塞 DDL - 加索引前先
EXPLAIN ALTER TABLE t ADD INDEX idx_a (a)（MySQL 8.0.12+ 支持），看输出中ALTER_METHOD是否为INPLACE - 避免在业务高峰执行；如果表有百万级以上行，哪怕支持 inplace，也会持续占用 I/O 和 CPU，影响查询响应时间
pt-online-schema-change 怎么用才不翻车？
pt-online-schema-change 是 Percona Toolkit 提供的“无锁”改表工具，原理是建影子表、同步数据、原子切换。但它不是银弹——配置不当反而引发主从延迟、binlog 爆涨、甚至主键冲突。
使用场景：必须在线加索引，且不能接受任何写入中断（哪怕几秒）；表有主键或唯一非空索引（否则无法安全同步）。
- 务必加
--chunk-size=1000（默认 1k 行/次），防止单次 UPDATE 太大拖慢主库；对高 QPS 表可压到 100–500 - 必须指定
--check-interval=1（秒级检测），并配--max-lag=1，一旦从库延迟超 1 秒自动暂停，避免雪崩 - 禁止在
replication_filter过滤了该表的从库上运行；也不要在 GTID 模式下省略--set-vars="FOREIGN_KEY_CHECKS=0"，否则可能因外键校验失败中断 - 执行前先跑
--dry-run，它会模拟建影子表、检查触发器权限、验证主键，比直接跑更早暴露问题
CREATE INDEX CONCURRENTLY 在 MySQL 里存在吗？
不存在。CREATE INDEX CONCURRENTLY 是 PostgreSQL 的语法，MySQL 没有对应能力。有人误以为 ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE 就等同于它，但实际仍有细微锁点：DDL 开始和结束时需短暂获取 MDL_WRITE 锁（毫秒级），对超高频写入仍可能触发排队。
参数差异很关键：LOCK=NONE 仅保证 DML 不被阻塞，但 LOCK=SHARED 会阻塞写入、LOCK=DEFAULT 由 MySQL 自判（往往偏保守）。
- 不要依赖
LOCK=NONE声明就认为“完全无感”，尤其在连接池满、网络抖动时，那几十毫秒的 MDL 等待可能放大成大量请求超时 - 如果表上有全文索引、空间索引、或使用 MyISAM 引擎，
ALGORITHM=INPLACE直接不可用，会报错ALGORITHM=INPLACE is not supported for this operation - MySQL 8.0 对二级索引创建做了优化（如并行排序），但前提是
innodb_sort_buffer_size足够大，否则仍 fallback 到单线程 merge
为什么加完索引查询没变快？
索引建了，EXPLAIN 显示也用了，但慢查询日志里还是高频出现——大概率是统计信息没更新，优化器选错了执行路径，或者索引本身设计不合理。
性能影响常被忽略：MySQL 的索引统计（cardinality）默认只在 ANALYZE TABLE 或表变更量达 1/16 时才自动更新。大表加完索引后，旧统计还在，优化器可能继续走全表扫描。
- 加索引后立刻执行
ANALYZE TABLE t，强制刷新统计信息；生产环境建议关掉innodb_stats_auto_recalc=OFF，改为定时ANALYZE - 检查索引是否覆盖查询字段：如果
SELECT a,b,c FROM t WHERE a=1，而索引是(a)，就会回表；应建(a,b,c)覆盖索引 - 注意隐式类型转换：比如
WHERE phone = 13800138000（phone 是VARCHAR），会导致索引失效，EXPLAIN中type变成ALL
