# 1. MySQL InnoDB Online DDL 加列，ALGORITHM=INSTANT、INPLACE？ A INPLACE 加列必须阻塞所有读写 B INSTANT 需要全表重建，最慢 C INSTANT 只改元数据几乎瞬时完成，INPLACE 原地修改，两者都支持在线并发 DML ✓ 正确答案 D 加列只能使用 COPY 算法
# 2. PostgreSQL 11+ 加列的优化，ALTER TABLE ADD COLUMN 默认值不重写表？ A PostgreSQL 加列永远需要重写表 B 任何默认值都会触发全表重写 C 加列必须加 NOT NULL 才能不重写 D 常量默认值作为元数据存储，加列不重写表且不阻塞 ✓ 正确答案
# 3. 加列的默认值（DEFAULT）设置，DEFAULT 与 NOT NULL 的协同？ A 加 NOT NULL 列需提供 DEFAULT 给存量行兜底，常量默认值可在线快速完成 ✓ 正确答案 B NOT NULL 列不需要 DEFAULT，已有行自动填值 C 加 NOT NULL 列必须重写整张表 D DEFAULT 与 NOT NULL 相互冲突，不能同时使用
# 4. MySQL Online DDL 加列？ A 加列必须 COPY，无法在线 B 三种算法都完全相同，无性能差异 C INSTANT 只改元数据，INPLACE 允许并发 DML，COPY 会全表重建并阻塞 ✓ 正确答案 D INSTANT 加列会阻塞所有并发 DML
# 5. 在线建索引的失败回滚，CONCURRENTLY 的 REINDEX？ A REINDEX CONCURRENTLY 无法在线执行 B CONCURRENTLY 失败会自动回滚到干净状态 C CONCURRENTLY 建索引会阻塞表读写 D 失败会残留无效索引，需 DROP 后重试，而非自动回滚 ✓ 正确答案
# 6. 在线建索引的代价，构建时间、I/O 消耗？ A 在线建索引与数据量无关，总是瞬时完成 B 在线建索引没有任何资源消耗 C 在线建索引只影响主库，不影响从库 D 在线建索引会消耗 I/O、CPU 与临时空间，并可能造成主从复制延迟 ✓ 正确答案
# 7. PostgreSQL 中类型变更的 USING 子句？ A USING 用于显式指定旧值到新类型的转换表达式，无隐式转换时必须使用 ✓ 正确答案 B USING 只在无需转换时使用 C 类型变更永远不重写表 D USING 会绕过所有转换，直接赋值
# 8. 列类型变更（ALTER COLUMN TYPE）的代价，表重写、锁等待？ A 类型变更只影响新插入的数据，存量行不受影响 B 类型变更从不重写表，也不阻塞 C 多数类型变更需全表重写并持有排他锁阻塞读写，大表应改用影子列渐进切换 ✓ 正确答案 D 类型变更永远瞬时完成
# 9. 回填（Backfill）的实现，分批 UPDATE、影子列？ A 分批 UPDATE 会永久阻塞表，无法使用 B 回填必须一次性更新全表，才最可靠 C 影子列方案不需要回填旧数据 D 分批 UPDATE 按主键逐批提交控制资源占用，影子列双写提供渐进平滑切换 ✓ 正确答案
# 10. MySQL 大版本升级（mysql_upgrade）的工具链？ A mysql_upgrade 用于升级系统表，MySQL 8.0 起融入 mysqld 启动流程自动升级 ✓ 正确答案 B mysql_upgrade 用于删除数据，升级前无需备份 C 大版本升级不需要任何工具，直接替换二进制即可 D mysql_upgrade 只用于监控，不参与升级
# 11. PostgreSQL 大版本升级（pg_upgrade）的实现，原地升级 vs 逻辑复制？ A 逻辑复制比 pg_upgrade 更简单 B pg_upgrade 必须全量拷贝数据，停机数天 C pg_upgrade 用链接模式原地升级停机短，逻辑复制可近乎零停机但设置复杂 ✓ 正确答案 D 大版本升级无需任何数据迁移
# 12. ORM 自动生成 DDL 与手写 DDL 的对比？ A ORM 生成的 DDL 与手写 DDL 完全等价 B ORM 自动 DDL 完全满足生产需求，无需手写 C 手写 DDL 无法控制索引与分区 D ORM 自动 DDL 开发便捷但生产不可控，手写 DDL 配合迁移工具适合生产 ✓ 正确答案
# 13. 影子流量的实现，TCP 复制、CDC、应用层双写？ A 影子流量会直接修改生产数据，影响业务 B TCP 复制镜像请求验证新版本，CDC 同步增量到影子库，应用层双写对比数据一致性 ✓ 正确答案 C 影子流量只能用于 TCP 层，无法应用层实现 D 影子流量与数据验证无关，仅用于压测
# 14. 影子流量（Shadow Traffic）的概念，将生产流量复制到新版本/新数据库？ A 影子流量只用于压测，不验证正确性 B 影子流量会直接改动生产数据 C 影子流量把生产流量复制到新环境验证正确性，同时保持与生产逻辑隔离 ✓ 正确答案 D 影子流量无法复制数据库增量
# 15. pt-online-schema-change 的工作原理（创建影子表 → 在原表建 INSERT/UPDATE/DELETE 三个触发器同步增量 → 分批拷贝存量 → RENAME 互换）是什么？触发器带来哪些额外写放大与风险？ A pt-osc 的触发器不会有任何写放大 B pt-osc 不使用触发器，直接改原表 C pt-osc 需要停机，无法在线 D 用三个触发器同步增量到影子表，分批拷贝存量后 RENAME 切换，但触发器带来写放大 ✓ 正确答案
# 16. gh-ost 如何通过解析 binlog（而非触发器）把增量应用到 ghost 表？cut-over 阶段借助辅助表与 RENAME 原子切换的关键步骤是什么？ A gh-ost 无法解析 binlog，只能全量拷贝 B gh-ost 依赖触发器同步增量 C gh-ost 解析 binlog 同步增量到 ghost 表，cut-over 用辅助表与原子 RENAME 完成切换 ✓ 正确答案 D gh-ost 的 cut-over 需要长期锁表，无法在线
# 17. gh-ost 如何通过 --max-load、--critical-load、--max-lag-millis 限流，并通过 Unix socket 命令（throttle/pause/cutover/cancel）做运行期控制？ A gh-ost 没有任何限流机制 B max-load/critical-load 按主库负载限流，max-lag-millis 按从库延迟限流，socket 命令提供运行期控制 ✓ 正确答案 C socket 命令只能启动时设定，无法运行期控制 D max-lag-millis 与从库延迟无关
# 18. 数据库迁移与应用发布的顺序（migration first vs app first）与 Expand-Contract 的落地 A migration first 与 Expand-Contract 无关 B app first 永远最优，先发布应用再改库 C Expand-Contract 先加后删，让迁移与发布解耦、可回滚，是零停机 Schema 演进的标准做法 ✓ 正确答案 D 迁移与发布必须同一时刻原子完成
# 19. pt-osc 与 gh-ost 如何选型，触发器开销与已有触发器冲突、外键处理（alter-foreign-keys-method）、主从延迟控制、可暂停性方面的差异？ A 两者都不支持主从延迟控制 B 两者都使用触发器，无区别 C gh-ost 无法处理外键，pt-osc 也无法处理 D gh-ost 解析 binlog 无触发器写放大、可暂停控制强，pt-osc 外键处理更完善 ✓ 正确答案
# 20. gh-ost/pt-osc 的行拷贝批次（chunk-size/rows-per-chunk）如何控制？为什么要求表上有唯一键/主键才能安全分批？ A 批次与唯一键无关，只是性能优化 B 批次大小无法控制，只能全量拷贝 C 无唯一键的表也能安全分批 D 批次用 chunk-size 控制，唯一键/主键提供切分锚点与去重依据，是安全分批的前提 ✓ 正确答案
# 21. 哪些 DDL 不适合用在线改表工具（重命名被触发器引用的列、修改主键定义、全文/空间索引）？各自的风险点是什么？ A 全文索引最适合在线工具处理 B 在线工具可安全处理任意 DDL，无限制 C 修改主键不影响在线工具运行 D 重命名被触发器引用的列、修改主键、全文/空间索引会破坏工具的分批与增量同步机制 ✓ 正确答案
# 22. MySQL 8.0 INSTANT DDL 覆盖加列等操作后，第三方在线改表工具仍不可替代的场景有哪些（列类型变更、大表改字符集、重建聚簇索引）？ A 重建聚簇索引可用 INSTANT 无成本完成 B INSTANT 覆盖所有 DDL，工具已无必要 C 改字符集可用 INSTANT 完成 D 列类型变更、大表改字符集、重建聚簇索引等涉及数据重写的 DDL 仍需在线工具 ✓ 正确答案
# 23. 在线改表工具如何与主从架构配合（--check-slave-lag 指定延迟检测从库、主从延迟超阈值自动暂停）？ A --check-slave-lag 指定从库检测延迟，超阈值自动暂停拷贝保护从库 ✓ 正确答案 B 在线改表会随意放大从库延迟，无任何保护 C 从库延迟与在线改表无关 D 在线改表只影响主库，不影响从库
# 24. 数据库迁移（Migration）的版本管理，Flyway、Liquibase、sqitch？ A 三种工具功能完全相同，可任意互换 B Flyway 用版本化 SQL 简单直接，Liquibase 用 changelog 抽象，sqitch 用依赖图支持精细回滚 ✓ 正确答案 C Flyway 不支持版本记录 D sqitch 无法回滚
# 25. 迁移漂移（Drift）的检测，schema 与代码不一致？ A 漂移无法检测，只能靠经验 B 漂移是 schema 与代码不一致，靠 diff 工具对比实际与期望 schema 检测，靠流程预防 ✓ 正确答案 C 漂移只影响测试环境，不影响生产 D 人工直接改库不会造成漂移
# 26. 迁移脚本的向前兼容与回滚策略，Expand-Contract 模式？ A 迁移脚本无需向前兼容，直接改即可 B Expand-Contract 先加后删，保证旧应用兼容且每步可回滚，是标准做法 ✓ 正确答案 C 回滚策略与兼容性无关 D Expand-Contract 只用于加列，不用于回滚
# 27. 零停机迁移（Zero-Downtime Migration）的实践，影子流量、双写？ A 零停机迁移必须一次性停机完成 B 通过影子流量验证、双写保证一致、对账、灰度切换与清理实现渐进式无停机迁移 ✓ 正确答案 C 影子流量与双写无关，各做各的 D 零停机迁移无法回滚
# 28. Expand-Contract 与一致性？ A Expand-Contract 会破坏迁移期间的一致性 B Expand-Contract 与一致性无关，只影响性能 C Expand-Contract 分批加删并存，配合双写对账让迁移期保持数据一致 ✓ 正确答案 D Expand-Contract 必须一次性原子切换才能保证一致
# 29. Contract 阶段，删除旧列、旧表？ A 在确认应用全部使用新结构后删除旧列/旧表，删除不可逆需谨慎并保留回滚预案 ✓ 正确答案 B Contract 阶段应尽快删除旧结构，无需确认 C 删除旧结构可随时回滚，无风险 D Contract 阶段是 Expand 阶段的前置步骤
# 30. Expand 阶段，加列加表，不删除旧结构？ A Expand 阶段只新增结构不删旧结构，保证向前兼容且回滚成本低 ✓ 正确答案 B Expand 阶段应同时删除旧结构，节省空间 C Expand 阶段会破坏旧应用兼容性 D Expand 阶段不可逆，风险最高
# 31. Expand-Contract 与在线 DDL 的协同？ A 在线 DDL 与 Expand-Contract 无关，各自独立 B Expand-Contract 编排加删流程，在线 DDL 提供零停机的执行手段，共同实现全程零停机 ✓ 正确答案 C 在线 DDL 无法用于 Expand 阶段 D Expand-Contract 必须停机才能执行 DDL
# 32. Expand-Contract 模式的三阶段，扩展（Expand）、迁移（Contract）、清理（Cleanup）？ A 三阶段一次性完成，无中间验证 B Expand 加新结构、Contract 切换新结构、Cleanup 清理旧结构，每阶段可验证可回滚 ✓ 正确答案 C Contract 阶段就删除旧结构 D Cleanup 阶段是第一步，先删旧结构
# 33. 大表改键的回滚（在迁移与在线 DDL 范畴内）？ A 用影子表+切换方案保留旧表，回滚只需 RENAME 切回，避免重跑耗时的改键 ✓ 正确答案 B 大表改键可随时回滚，无需备份 C 改键回滚与改键本身代价相同，无差异 D 大表改键不影响在线业务，可随意执行
# 34. 分区数据的重分布（Rebalance），Online vs Offline？ A Offline 停机重建简单可靠，Online 渐进迁移零停机但复杂，按停机窗口与数据量选型 ✓ 正确答案 B 分区重分布必须停机，无法在线 C Online 重分布与 Offline 完全等价 D 分区键变更不影响重分布
# 35. 分区表的拆分（Detach/Attach）与重组？ A DETACH 分区后无法再挂回 B 分区拆分必须重建整个父表 C DETACH/ATTACH 可低成本分离/挂接分区用于归档扩容，重组需建新布局并迁移数据 ✓ 正确答案 D 分区重组与数据边界无关
# 36. 分区表（Partitioned Table）的迁移，从普通表转为分区表？ A 迁移只需一次全量 INSERT，无需分批 B 普通表可直接原地转分区表，无需迁移数据 C 分区键随便选，不影响性能 D 建分区表、按范围分批迁移、校验后 RENAME 切换，分区键选择决定查询裁剪与数据均衡 ✓ 正确答案
# 37. 跨版本升级的测试策略，影子库、A/B 测试？ A 影子库与 A/B 测试无关，各自独立 B 升级无需测试，直接生产执行 C 影子库验证正确性，A/B 灰度冒烟验证真实表现，再逐步放量切换 ✓ 正确答案 D 影子库会污染生产数据
# 38. Schema Diff 工具，migra、pgdiff、apgdiff、mydbforge？ A migra 只支持 MySQL B 所有 diff 工具都支持所有数据库，无差异 C Schema Diff 工具无法生成迁移脚本 D migra/apgdiff 用于 PostgreSQL 差异对比，dbForge 等商业工具支持跨库可视化对比 ✓ 正确答案
# 39. 生产与测试环境的 Schema 一致性检测？ A 用 diff 工具对比两端 schema，关键靠统一迁移流程 + CI 自动校验来维护一致 ✓ 正确答案 B 一致性检测只能靠人工肉眼比对 C 测试环境与实际生产无需保持一致 D 迁移流程统一与否不影响一致性
# 40. Schema 对比的最佳实践（在迁移与在线 DDL 范畴内）？ A 在线 DDL 的代价与 Schema 对比无关 B Schema 对比只在迁移时做一次，无需定期 C 对比只需人工，无需工具 D 迁移前后对比确认变更与落地，定期巡检检测漂移，并用自动化工具纳入 CI ✓ 正确答案
# 41. 影子流量的实现（在迁移与在线 DDL 范畴内）？ A 用 CDC 或应用层双写把真实流量复制到影子库验证新结构，保持隔离不污染生产 ✓ 正确答案 B 影子流量会直接修改生产数据 C 影子流量无法验证新结构的性能 D 影子流量与在线 DDL 无关
# 42. 在线改表完成后如何校验数据一致性（pt-table-checksum）？cut-over 之后发现问题如何回滚？ A 改表完成后无需校验，直接可用 B pt-table-checksum 逐行校验一致性，cut-over 后回滚依赖切换前保留旧表 ✓ 正确答案 C cut-over 后无法回滚，只能修复 D pt-table-checksum 只能校验行数，无法发现差异
# 43. Flyway 在数据库版本管理中的应用，V/R/U 脚本命名与校验和机制、baseline 与 repair 的适用场景，如何与 Expand-Contract 发布策略配合？ A baseline 用于删除已执行的迁移 B Flyway 脚本可随意修改，无需校验和 C V/R/U 脚本命名区分迁移类型，校验和防篡改，baseline/repair 处理存量库与异常状态 ✓ 正确答案 D Flyway 与 Expand-Contract 无法配合
# 44. Liquibase 在企业数据库变更管理中的应用，changelog 的幂等执行与 checksum 校验，与 Flyway 在多人协作与复杂回滚上的差异如何选择？ A Liquibase 无法定义回滚 B Liquibase 与 Flyway 完全等价，无差异 C Liquibase 只支持 XML，不支持 SQL D Liquibase 用 changeset 幂等执行与 checksum 校验，支持复杂回滚，适合大型企业复杂变更 ✓ 正确答案
# 45. sqitch 的部署模型与 Flyway/Liquibase 有何不同，基于变更依赖图与回滚编排的设计思路，适合哪些多环境协作场景？ A sqitch 基于变更依赖图部署，按依赖逆序回滚，适合复杂依赖与精细回滚场景 ✓ 正确答案 B sqitch 与 Flyway 一样按版本号排序执行 C sqitch 无法回滚，只能部署 D sqitch 只适合单环境简单项目
# 46. 跨库数据迁移后的校验与对账（抽样比对、计数比对、增量追平） A 迁移后无需对账，直接切换 B 对账只需计数，无需抽样 C 计数比对发现量的差异，抽样比对发现值差异，增量追平补齐迁移期间新数据 ✓ 正确答案 D 增量追平与迁移无关
# 47. 迁移窗口与发布窗口的编排（维护窗口、回滚条件与通知） A 低峰维护窗口内执行，库迁移先于应用发布，预设回滚条件并做好通知 ✓ 正确答案 B 迁移与发布可以随时任意执行，无需编排 C 回滚条件无需预先定义，失败再想 D 通知与迁移编排无关
