标准答案
- 确认目标数据库版本和具体 DDL 支持的在线算法、锁级别及限制，不要把“online”当作零影响承诺。
- 检查是否存在长事务、慢查询或未提交连接，它们可能让 DDL 等待元数据锁并反过来阻塞新请求。
- 评估大表重建、索引创建和日志生成对磁盘、CPU、IOPS、临时空间和复制链路的影响。
- 在预发或影子环境按接近生产的数据规模演练，设定观察指标、停止条件和变更窗口。
- 必要时使用分批迁移、影子表、在线 schema change 工具或先扩展后切流方案，确保可恢复。
题目解析
DDL 风险往往来自等待而非真正执行时间。一个秒级 ALTER 因为被长事务持有的元数据锁挡住，可能排队数分钟；其后所有访问同表的新请求也被堵住，表现为业务整体超时。
副本延迟是另一个常见尾部风险。主库快速完成变更不代表副本能及时回放，读写分离和故障切换窗口可能随之变得不可靠。
常见误区
- 只在测试空表验证 DDL 成功，就直接在生产大表上执行。
- 看到主库 DDL 完成即结束变更，没有继续观察副本延迟、错误率和锁等待。