无锁变更需规避MDL锁，大表用影子表+双写+原子切换；MySQL/PG部分DDL支持在线（如加列、增索引），但MODIFY COLUMN等仍需影子表；须应用、中间件、监控协同，并注意字符集、外键、分区表等细节。
SQL表结构变更在高并发生产环境中，最怕锁表导致服务中断。无锁变更的核心是避免ALTER TABLE直接加元数据锁（MDL）阻塞读写，尤其对大表（千万级以上）必须绕过“原地修改”模式，改用“影子表+数据迁移+原子切换”流程。
识别哪些操作天然支持无锁
不是所有DDL都能无锁，MySQL 5.6+ 和 PostgreSQL 对部分操作做了优化：
-
MySQL Online DDL：添加列（
AFTER位置）、修改列默认值、增删二级索引（不含主键）、重命名索引——只要不涉及行数据重排，且使用ALGORITHM=INPLACE, LOCK=NONE显式指定，多数可在线完成 -
PostgreSQL：添加列（不带
NOT NULL或默认值）、重命名列/索引、增加唯一约束（不含验证历史数据）——本质是仅修改系统表，不触碰数据页 - 注意：
MODIFY COLUMN、CHANGE COLUMN、删除列、修改主键、添加NOT NULL约束等，仍会触发全表拷贝或强锁，需走影子表方案
大表变更必须用影子表（Shadow Table）流程
适用于需重写数据的变更（如字段类型调整、拆分冗余列、编码转换等），核心是“双写+校验+切换”，全程不锁原表：
- 新建影子表（如
users_new），定义目标结构，建好索引和约束 - 启动双写：应用层或通过触发器/中间件，确保新旧表同步写入（写旧表的同时写新表）
- 执行数据迁移：用
pt-online-schema-change（MySQL）或pg_cron + COPY + window function（PG）分批次迁移存量数据，每批控制在1~5万行，避免长事务 - 校验一致性：对比新旧表行数、关键字段校验和（如
CRC32(CONCAT(...))聚合）、抽样查询比对 - 原子切换：在一个短事务内，
RENAME TABLE users TO users_old, users_new TO users（MySQL）或ALTER TABLE ... RENAME+DROP（PG）
应用与基础设施协同要点
无锁不是DBA单方面能搞定的，需要上下游配合：
- 应用层适配：切换前需支持同时读新旧表（如配置化表名），切换后及时下线旧表访问逻辑；双写期间异常需有降级（如只写主表+异步补新表）
- 中间件支持：若用ShardingSphere、MyCat等，须提前更新逻辑表映射，避免路由错乱；分库分表场景下，每个分片需独立执行影子表流程
-
监控兜底：实时跟踪迁移进度、延迟（如
pt-osc的--chunk-time日志）、主从同步位点偏移；设置超时自动中止，防止拖垮主库
别忽略小细节：字符集、外键、分区表
这些看似边缘的情况，常在线上引发隐性锁或失败：
- 修改字段字符集（如
utf8mb4→utf8mb4_0900_as_cs）：MySQL 8.0+ 支持ALGORITHM=INSTANT，但低版本仍需全量重建，务必查information_schema.INNODB_TABLES确认是否支持 - 含外键的表：影子表需重建外键引用关系，且切换前要停写关联表，否则
RENAME会因外键约束报错 - 分区表：MySQL 分区表
ALTER可能触发LOCK=SHARED，建议先EXCHANGE PARTITION迁移单个分区，再逐个替换
