测验：DDL 与变更管理

“有 down 迁移脚本，所以是安全的”这一判断有什么问题？

• DBMS 不支持 down 脚本
• down 脚本的执行时间总是更长
• down 脚本无法恢复索引
• 用于撤销 DROP 的 down 脚本只能恢复列结构，无法找回已经消失的数据

在一个事务中对 500 万行表执行大规模回填 UPDATE，会对查询服务产生什么影响？

• 事务日志暴增、复制滞后，读取副本的查询会返回旧数据
• 更新在独立会话中运行，对查询没有影响
• 大规模更新期间索引会暂时停用，导致查询变慢
• 更新结束前表会变为只读，只阻止写入

扩展—迁移—收缩（Expand/Migrate/Contract）模式的核心规则是什么？

• 把所有变更放在一次部署中，以缩短停机时间
• 架构变更必须始终晚于应用部署
• 先创建索引，再添加列
• 不要在一次部署中合并两个阶段，使每个时点都能回滚

以下哪项正确概括了添加列和删除列的部署顺序？

• 添加时先改数据库、后部署应用；删除时先改应用、后改数据库
• 两者都先改数据库
• 两者都先部署应用
• 添加时先部署应用，删除时先改数据库

为什么蓝绿部署不能解决架构变更问题？

• 蓝绿部署是应用专用策略，无法用于数据库层
• 切换后旧环境会被清理，因此没有回退手段
• 切换瞬间会中断会话，无法做到完全不停机
• 即使复制了计算环境，数据库仍然共享，因此架构必须同时兼容新旧版本

迁移验证只比较行数和合计值，可能漏掉哪种情况？

• 一条记录遗漏、另一条重复，合计值却恰好相同
• 整张表为空
• 索引未创建
• 列类型发生变化

把“回滚脚本路径”设为变更管理台账的必填项，最大的作用是什么？

• 统一台账字段，加快评审和审批流程
• 在编写回滚方案时，会在部署前发现“该变更无法撤销”
• 准备好回滚脚本后，就能更激进地执行 DDL
• 有回滚计划即可跳过一次审批，缩短进度