add index卡在waiting for table metadata lock根本原因不是索引操作慢，而是其他事务持有shared mdl锁阻塞alter获取exclusive锁；常见诱因包括未提交事务、长查询、空闲连接持隐式事务，需通过performance_schema.metadata_locks和innodb_trx联合定位持锁者。
不是加了ALGORITHM=INPLACE就真不锁表——MySQL 8.0添加索引阻塞，往往卡在元数据锁（MDL）或底层引擎限制上，而不是索引本身。
为什么ADD INDEX会卡在Waiting for table metadata lock
这几乎从不因为索引操作本身慢，而是因为有其他事务正持有该表的SHARED MDL锁，导致ALTER无法获取EXCLUSIVE MDL锁。常见诱因包括：
- 一个未提交的
SELECT ... FOR UPDATE或长事务正在执行，哪怕只是读一行 - 另一个
ALTER、DROP TABLE或TRUNCATE语句正在排队等待 - 应用层连接池里有空闲但未关闭的连接，仍持有隐式事务（如autocommit=OFF后只执行了
SELECT）
查证方式：SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_TYPE = 'TABLE' AND LOCK_STATUS = 'PENDING'; 看谁在等；再用SELECT trx_id, trx_started, trx_state, trx_query FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 5; 找出最早未提交的事务。
ADD INDEX触发copy to tmp table说明什么
状态显示copy to tmp table，代表MySQL已降级为ALGORITHM=COPY，全程排他锁，所有DML被阻塞。这不是配置错了，而是操作不满足INPLACE前提：
- 加的是
FULLTEXT或SPATIAL索引（InnoDB不支持在线创建） - 表使用MyISAM引擎（根本无
INPLACE能力） - 目标列是
TEXT或BLOB且定义了DEFAULT值（触发全表初始化） - MySQL版本低于5.6，或启用了
innodb_file_per_table=OFF（部分老配置下退化）
注意：SHOW PROCESSLIST里看到altering table≠安全——它可能已在copy阶段卡住数小时。
为什么LOCK=NONE写了也报错或无效
LOCK=NONE仅对极少数变更生效，写错参数或操作类型不匹配会直接报错或静默降级：
-
ERROR 1846 (HY000): LOCK=NONE is not supported：比如ADD COLUMN c INT AFTER id（指定位置）、MODIFY COLUMN c VARCHAR(200)（缩小长度）、或加UNIQUE KEY（即使数据唯一，MySQL也强制COPY） - 没报错但实际锁表：比如
ADD INDEX时表上有FOREIGN KEY约束，或字段类型为JSON且MySQL -
ALGORITHM=INSTANT虽快，但仍需MDL-X锁——它跳过数据拷贝，但不跳过元数据变更锁
真正能放心用LOCK=NONE的只有：ADD INDEX、DROP INDEX、末尾ADD COLUMN（无DEFAULT或DEFAULT NULL）、改DEFAULT值。
从库延迟放大不是DDL本身的问题
主库ADD INDEX耗时10秒，从库可能延迟数小时——这不是锁表，而是复制机制导致：
- 从库必须重放整个
ALTER语句，不能跳过或并行执行（除非开启slave_parallel_type = LOGICAL_CLOCK且slave_preserve_commit_order = ON） - 从库I/O或CPU瓶颈时，
ALTER会阻塞后续所有binlog事件回放 -
pt-online-schema-change或gh-ost绕过此问题，但引入了双写一致性风险和额外延迟
线上加索引前，务必先确认从库负载和复制参数；若无法停主从，优先考虑影子表方案而非原生ALTER。
最常被忽略的一点：ALGORITHM=INPLACE和LOCK=NONE是独立参数，组合生效才有意义；而MDL锁等待和引擎层拷表是两类完全不同的阻塞源头，排查时必须分开验证——前者看performance_schema.metadata_locks，后者看SHOW PROCESSLIST状态和错误日志。
