MySQL Online DDL不锁表不代表没有风险一、Online DDL 也会影响业务MySQL 支持 Online DDL 后很多人看到ALGORITHMINPLACE或LOCKNONE就放松警惕。但“不锁表”不代表没有风险。DDL 可能带来元数据锁等待、写入放大、临时空间增长、复制延迟和回滚困难。生产库 DDL 的第一原则是把影响算清楚。二、先识别 DDL 类型flowchart TD A[DDL] -- B[元数据变更] A -- C[索引构建] A -- D[列变更] A -- E[表重建]不同 DDL 的风险差异很大。新增二级索引和修改列类型不是一个级别Instant、Inplace、Copy 的成本也不同。执行前要确认实际算法而不是只看语法期望。ALTER TABLE orders ADD INDEX idx_user_created(user_id, created_at), ALGORITHMINPLACE, LOCKNONE;执行计划和版本差异都要确认。同一条 DDL 在不同 MySQL 版本上可能行为不同。三、元数据锁要重点盯DDL 最怕被长事务卡住元数据锁同时又阻塞后续业务 SQL。上线前要检查长事务、未提交连接和慢查询。执行中要监控 MDL 等待。SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_NAME orders;如果发现等待链应该及时中止而不是赌它很快结束。四、复制和空间也要算新增索引会消耗 IO 和临时空间主库执行完不代表从库跟得上。主从延迟扩大时读流量如果还打到从库可能出现读旧数据或延迟雪崩。ddl_guard: check_long_transaction: true monitor_mdl: true monitor_replica_lag: true require_disk_free_ratio: 0.3大表 DDL 更适合用灰度或工具分批执行例如 pt-online-schema-change 或 gh-ost。工具不是免死金牌触发器、binlog、外键和业务写入压力仍要评估。最后DDL 也需要回滚方案。新增索引可以删除修改列类型就没那么轻松。越难回滚越要在低峰、备份和演练上多花时间。变更窗口也要根据业务写入曲线选择。低峰不是只看 QPS还要看长事务、批处理、备份、报表和主从延迟。很多 DDL 事故发生在“看起来没什么流量”的后台作业时间。ddl_window_check: low_write_qps: true no_large_batch_job: true backup_not_running: true replica_lag_normal: true执行期间要设置阶段性停止点。比如索引构建开始后发现 IO 飙升就要及时评估是否中止从库延迟超过阈值就要暂停后续变更。DDL 不是按下回车就只能祈祷。最后变更记录要写清实际耗时、影响指标和异常处理。下一次同类表结构调整时这些历史数据比经验口头传递可靠。对于特别大的表还可以先在影子库或恢复出的备份库上演练。演练不能完全等价于生产压力但能提前发现算法退化、临时空间不足和工具参数错误。DDL 最怕第一次执行就是生产执行。ddl_rehearsal: restored_snapshot: true estimate_duration: true estimate_temp_space: true verify_tool_options: true五、总结MySQL Online DDL 要关注算法、元数据锁、长事务、复制延迟、临时空间和回滚难度。不锁表不代表没有风险。DDL 是变更不是普通 SQL。
MySQL Online DDL：不锁表不代表没有风险
MySQL Online DDL不锁表不代表没有风险一、Online DDL 也会影响业务MySQL 支持 Online DDL 后很多人看到ALGORITHMINPLACE或LOCKNONE就放松警惕。但“不锁表”不代表没有风险。DDL 可能带来元数据锁等待、写入放大、临时空间增长、复制延迟和回滚困难。生产库 DDL 的第一原则是把影响算清楚。二、先识别 DDL 类型flowchart TD A[DDL] -- B[元数据变更] A -- C[索引构建] A -- D[列变更] A -- E[表重建]不同 DDL 的风险差异很大。新增二级索引和修改列类型不是一个级别Instant、Inplace、Copy 的成本也不同。执行前要确认实际算法而不是只看语法期望。ALTER TABLE orders ADD INDEX idx_user_created(user_id, created_at), ALGORITHMINPLACE, LOCKNONE;执行计划和版本差异都要确认。同一条 DDL 在不同 MySQL 版本上可能行为不同。三、元数据锁要重点盯DDL 最怕被长事务卡住元数据锁同时又阻塞后续业务 SQL。上线前要检查长事务、未提交连接和慢查询。执行中要监控 MDL 等待。SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_NAME orders;如果发现等待链应该及时中止而不是赌它很快结束。四、复制和空间也要算新增索引会消耗 IO 和临时空间主库执行完不代表从库跟得上。主从延迟扩大时读流量如果还打到从库可能出现读旧数据或延迟雪崩。ddl_guard: check_long_transaction: true monitor_mdl: true monitor_replica_lag: true require_disk_free_ratio: 0.3大表 DDL 更适合用灰度或工具分批执行例如 pt-online-schema-change 或 gh-ost。工具不是免死金牌触发器、binlog、外键和业务写入压力仍要评估。最后DDL 也需要回滚方案。新增索引可以删除修改列类型就没那么轻松。越难回滚越要在低峰、备份和演练上多花时间。变更窗口也要根据业务写入曲线选择。低峰不是只看 QPS还要看长事务、批处理、备份、报表和主从延迟。很多 DDL 事故发生在“看起来没什么流量”的后台作业时间。ddl_window_check: low_write_qps: true no_large_batch_job: true backup_not_running: true replica_lag_normal: true执行期间要设置阶段性停止点。比如索引构建开始后发现 IO 飙升就要及时评估是否中止从库延迟超过阈值就要暂停后续变更。DDL 不是按下回车就只能祈祷。最后变更记录要写清实际耗时、影响指标和异常处理。下一次同类表结构调整时这些历史数据比经验口头传递可靠。对于特别大的表还可以先在影子库或恢复出的备份库上演练。演练不能完全等价于生产压力但能提前发现算法退化、临时空间不足和工具参数错误。DDL 最怕第一次执行就是生产执行。ddl_rehearsal: restored_snapshot: true estimate_duration: true estimate_temp_space: true verify_tool_options: true五、总结MySQL Online DDL 要关注算法、元数据锁、长事务、复制延迟、临时空间和回滚难度。不锁表不代表没有风险。DDL 是变更不是普通 SQL。
