解读

在国内多租户 SaaS 场景里，一个 Cloud SQL 实例常承载上百个租户，每个租户独占一个 PostgreSQL schema（或 MySQL database）。面试官想确认三件事：

1. 你能在秒级内完成 DDL 而不锁全库，不影响其他租户；
2. 删除后立即把磁盘空间还给 GCP，避免持续计费；
3. 整个过程可灰度、可回滚、符合等保/国密审计要求。
   因此“快速”不仅是操作快，还要兼顾业务连续性、账单、合规三大维度。

知识点

• PostgreSQL：DROP SCHEMA tenant_xx CASCADE 会先把对象标记为 dead，再逐表清垃圾；大 schema 可能触发长事务，导致 Cloud SQL 只读副本延迟飙高。
• MySQL：DROP DATABASE tenant_xx 是元数据操作，但 InnoDB 的 ibd 文件要后台 purge，空间不会立刻释放。
• Cloud SQL 存储模型：所有引擎共用自动扩容 SSD，删除后空间先变成“内部空洞”，账单仍按峰值收费；必须触发存储缩容（storage shrink） 或重建实例才能降账。
• 闪回与审计：国内金融客户要求7 天内可闪回，需先做一次闪回级备份（PITR） 再删；删除动作要写入Cloud AuditLogs并同步到金仓/达梦审计平台。
• 锁与并发：PostgreSQL 12+ 支持DROP SCHEMA ... CONCURRENTLY（预览特性），可拆分为ALTER TABLE ... SET SCHEMA old; DROP SCHEMA old; 两步，降低锁粒度。
• Terraform 流水线：国内常用阿里云云效+GitLab CI，通过terraform taint标记旧实例，重建新实例并挂载原磁盘快照，实现“逻辑删除+物理缩容”一体化。

答案

分四步，总耗时 < 5 分钟，业务零感知：

1. 预检与备份
   a. 用gcloud sql export sql ... --offload 把租户 schema 导出到国内双可用区 Cloud Storage（北京/上海），开启KMS 国密密钥加密；
   b. 执行gcloud sql backups create --async，拿到PITR 恢复点，满足等保要求。

2. 逻辑删除（低锁）
   PostgreSQL：

   SET lock_timeout = '2s';
   CREATE SCHEMA old;
   ALTER SCHEMA tenant_xx RENAME TO old;  -- 元数据锁仅几十毫秒
   DROP SCHEMA old CASCADE;               -- 后台异步回收
   

   MySQL：

   SET SESSION innodb_fast_shutdown = 0;
   RENAME DATABASE tenant_xx TO old;      -- 8.0 原子 DDL
   DROP DATABASE old;
   

3. 立即回收空洞
   在 Cloud SQL 控制台点击**“存储优化”** → “收缩存储”（仅 PostgreSQL 13+ 和 MySQL 8.0 支持），或执行

   gcloud sql instances patch <instance> --storage-auto-increase-limit=<新峰值GB>
   

   强制后台vacuum full/optimize table，账单次日生效。

4. 审计与通知
   通过Cloud Pub/Sub触发钉钉群机器人，推送“租户 xx 已删除，回收空间 xx GB，PITR 点保留 7 天”。

拓展思考

• 如果租户数据超 2 TB，直接DROP会触发长时间 vacuum，可把大表先TRUNCATE再DROP，或采用分区表按租户 detach → drop 的方式，把耗时从 30 分钟降到 30 秒。
• 国内跨省数据出境限制下，Cloud SQL 快照只能留在华北/华东双区域；若客户要求**“数据不出省”，可改用Private Service Connect + 本地 SSD 缓冲层**，删除后立刻fstrim回收块设备。
• 对MySQL 5.7（仍占国内 60% 份额），DROP DATABASE 不会缩小 ibdata1，只能逻辑导出→新建实例→切换域名，这是面试里常见的“坑”，务必强调版本差异。