解读

在国内云厂商的面试中，面试官常把“关闭外键检查”作为数据一致性与运维规范的考点。
Google Cloud SQL 提供 --no-auto-commit 与 --set-foreign-key-checks=0 两种开关，但默认不会强制校验导入脚本。
如果候选人只回答“会丢数据”，会被追问“怎么丢、丢在哪、如何防”；因此必须把风险场景、后果、检测手段、回滚方案一次性说透，才能体现“企业级运维”能力。

知识点

1. 外键（FOREIGN KEY） 的核心价值：行级引用完整性，防止孤儿记录。
2. MySQL 参数 foreign_key_checks 会话级生效，0 表示关闭，1 表示开启；Cloud SQL 导入作业默认以会话身份执行，不会自动回滚已提交数据。
3. Cloud SQL 导入通道：gsutil → Cloud Storage → 导入 API → 临时实例 → 目标实例；整个链路无全局事务屏障，关闭外键检查后逐条 COMMIT。
4. 风险分级：
   • 一级：产生孤儿记录，业务查询空指针。
   • 二级：级联更新/删除失效，库存、账务出现负值或超卖。
   • 三级：后续 DDL 失败（如添加外键）因现有数据不满足约束，导致在线变更窗口爆仓。
5. 国内合规：等保 2.0 要求金融与政务系统必须具备“数据可追溯与一致性校验”能力，关闭外键检查需双人复核+审计日志，否则年审直接扣分。
6. 检测手段：
   • 导入后执行 SELECT … WHERE NOT EXISTS (…) 做全表反连接，计算孤儿率。
   • 利用 Cloud SQL Insights 的异常检测，观察 QPS 突增与错误码 1452。
7. 回滚方案：
   • 若实例已开启点时间恢复（PITR），可直接恢复到导入前 1 分钟；
   • 若无 PITR，需用 gcloud sql export 生成 SQL 文件，手动写反向 DELETE 脚本，回滚窗口与数据量成正比，TB 级库可能超 30 分钟，不满足国内电商大促 5 分钟止血要求。

答案

关闭外键检查后，Cloud SQL 不再逐行验证引用完整性，会把不满足外键关系的脏数据直接写入，导致三大风险：

1. 业务逻辑错误：订单表出现不存在的 user_id，前端查询时空指针，用户看到空白订单，投诉率飙升。
2. 级联失效：父表删除记录时子表应同步删除，因外键被关闭变成孤立行，库存系统多扣或少扣库存，造成资损。
3. 后续 DDL 阻塞：想重新开启外键，必须先清理脏数据；大表全量扫描会锁表，Cloud SQL 的高可用切换窗口最长 60 秒，触发国内 SLA 99.95% 违约。
   防范措施：

• 导入前在沙箱实例做 dry-run，开启 foreign_key_checks=1 验证；
• 使用 Cloud Build + Terraform 流水线，把校验脚本作为强制门禁，CI 不通过自动回滚对象存储桶；
• 导入后立刻执行 checksum 任务，把孤儿记录数写入 Cloud Monitoring 自定义指标，超过阈值直接熔断发布并通知值班。

拓展思考

如果业务必须关闭外键（如分库分表后批量导数），如何兼顾一致性与性能？

1. 两阶段导入：先关闭外键，批量灌入；再开启外键，使用 ON DELETE IGNORE 的临时脚本异步清理孤儿数据，把一致性修复时间打散到低峰时段。
2. 利用 Cloud SQL for PostgreSQL 的 DEFERRABLE 外键：导入时把约束设为 INITIALLY DEFERRED，在同一个事务末尾一次性校验，既享受批量速度，又保证事务级原子性。
3. 国内双活架构：在深圳与上海双 Region 各建只读实例，导入前把流量切到深圳，上海做快照+校验；确认无误后切换 VIP，实现蓝绿发布，满足一行代码不掉单的金融级要求。