mysql大表加字段锁表主因是innodb默认用copy算法重建整表；仅当满足null/default、非主键等全部条件时才启用instant（秒级），否则降级为inplace（短锁）或copy（长锁）。
MySQL大表加字段锁表，根本不是配置没调好，而是InnoDB默认用COPY算法重建整张表——数据量越大，拷贝越久，排他MDL锁就握得越紧。所谓“离线DDL”，其实是误称；MySQL没有真正的离线模式，只有ALGORITHM=INSTANT（秒级）、ALGORITHM=INPLACE（短锁）、或退化回ALGORITHM=COPY（长锁）三种执行路径。
为什么ADD COLUMN会触发COPY算法？
关键看字段定义是否“可跳过数据重写”。MySQL只对满足以下全部条件的操作才启用ALGORITHM=INSTANT（8.0.12+）：
- 新增列必须是
NULL或带DEFAULT值（不能是NOT NULL且无默认值） - 不能是主键、唯一索引列、生成列、全文索引列
- 不能修改已有列的定义（哪怕只是改个注释）
- 表引擎必须是InnoDB，且未启用
innodb_file_per_table=OFF
一旦不满足任意一条，MySQL就会降级为INPLACE（仍需短暂锁）或直接fallback到COPY（全程锁表）。比如：ALTER TABLE t ADD COLUMN c INT NOT NULL; —— 因为没给DEFAULT，就必须逐行填0，只能COPY。
ALGORITHM=INPLACE也不等于零阻塞
ALGORITHM=INPLACE常被误解为“完全不锁”，其实它分三阶段：准备（毫秒级MDL写锁）、在线变更（允许DML并发）、提交（再抢一次毫秒级MDL写锁）。但以下情况会让锁时间不可控：
- 表上有长事务未提交：新DDL必须等它释放MDL读锁，期间所有新请求排队
- 磁盘IO瓶颈：即使不拷全表，
INPLACE仍要重写聚集索引页和二级索引页，SSD慢盘下可能卡在I/O - 高并发写入：大量
INSERT/UPDATE导致在线变更阶段日志堆积，延长提交等待
验证当前操作是否真走INPLACE，执行前加EXPLAIN FORMAT=TREE：
EXPLAIN FORMAT=TREE ALTER TABLE t ADD COLUMN x VARCHAR(10) DEFAULT '' ALGORITHM=INPLACE;
若输出含"access_type": "table_scan"，说明仍要扫全表，风险极高。
当必须用COPY时，怎么把业务影响压到最低？
别硬扛。直接跑ALGORITHM=COPY等于主动瘫痪服务。此时应切到外部工具，核心是“绕过MySQL原生DDL锁机制”：
- 用
pt-online-schema-change：适合MySQL 5.6–8.0，依赖触发器同步增量，但要注意触发器在高并发写入下可能拖慢主库 - 用
gh-ost：推荐高负载场景，不依赖触发器，靠解析binlog同步，但要求binlog_format=ROW且binlog_row_image=FULL - 手动影子表：仅限低流量窗口，步骤是
CREATE TABLE new_t LIKE old_t→ALTER TABLE new_t ADD COLUMN ...→INSERT INTO new_t SELECT *, DEFAULT_VALUE FROM old_t→RENAME TABLE old_t TO old_t_bak, new_t TO old_t；必须确保rename前无新写入，否则丢数据
注意：RENAME TABLE本身是原子操作，但耗时取决于表元数据大小，千万级表通常在100ms内，可接受。
真正容易被忽略的点是：锁表时间不只取决于SQL写法，更取决于当时实例上的MDL锁竞争状态。哪怕你写了ALGORITHM=INSTANT，只要会话里有未提交事务占着MDL_SHARED_READ，DDL就卡在“waiting for table metadata lock”——查performance_schema.metadata_locks比看执行计划还管用。
