MySQL 8.0在线DDL添加索引为什么仍会阻塞

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锁。常见诱因包括：

1. 一个未提交的SELECT ... FOR UPDATE或长事务正在执行，哪怕只是读一行
2. 另一个ALTER、DROP TABLE或TRUNCATE语句正在排队等待
3. 应用层连接池里有空闲但未关闭的连接，仍持有隐式事务（如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前提：

1. 加的是FULLTEXT或SPATIAL索引（InnoDB不支持在线创建）
2. 表使用MyISAM引擎（根本无INPLACE能力）
3. 目标列是TEXT或BLOB且定义了DEFAULT值（触发全表初始化）
4. MySQL版本低于5.6，或启用了innodb_file_per_table=OFF（部分老配置下退化）

注意：SHOW PROCESSLIST里看到altering table≠安全——它可能已在copy阶段卡住数小时。

为什么LOCK=NONE写了也报错或无效

LOCK=NONE仅对极少数变更生效，写错参数或操作类型不匹配会直接报错或静默降级：

1. ERROR 1846 (HY000): LOCK=NONE is not supported：比如ADD COLUMN c INT AFTER id（指定位置）、MODIFY COLUMN c VARCHAR(200)（缩小长度）、或加UNIQUE KEY（即使数据唯一，MySQL也强制COPY）
2. 没报错但实际锁表：比如ADD INDEX时表上有FOREIGN KEY约束，或字段类型为JSON且MySQL
3. ALGORITHM=INSTANT虽快，但仍需MDL-X锁——它跳过数据拷贝，但不跳过元数据变更锁

真正能放心用LOCK=NONE的只有：ADD INDEX、DROP INDEX、末尾ADD COLUMN（无DEFAULT或DEFAULT NULL）、改DEFAULT值。

从库延迟放大不是DDL本身的问题

主库ADD INDEX耗时10秒，从库可能延迟数小时——这不是锁表，而是复制机制导致：

1. 从库必须重放整个ALTER语句，不能跳过或并行执行（除非开启slave_parallel_type = LOGICAL_CLOCK且slave_preserve_commit_order = ON）
2. 从库I/O或CPU瓶颈时，ALTER会阻塞后续所有binlog事件回放
3. pt-online-schema-change或gh-ost绕过此问题，但引入了双写一致性风险和额外延迟

线上加索引前，务必先确认从库负载和复制参数；若无法停主从，优先考虑影子表方案而非原生ALTER。

最常被忽略的一点：ALGORITHM=INPLACE和LOCK=NONE是独立参数，组合生效才有意义；而MDL锁等待和引擎层拷表是两类完全不同的阻塞源头，排查时必须分开验证——前者看performance_schema.metadata_locks，后者看SHOW PROCESSLIST状态和错误日志。