解读

在国内面试场景里，这道题考察的是候选人对 Cloud SQL 克隆机制 与 PostgreSQL 内存模型 联动的深度理解。
面试官想确认两点：

1. 你是否知道 克隆 ≠ 字节级镜像，而是基于源实例的备份文件做时间点恢复（PITR）。
2. 你是否能解释 max_connections 的取值逻辑 在 Cloud SQL 侧与机器规格强绑定，而克隆时可能换了规格，导致最终值“缩水”。
   答不到“规格变化”与“Cloud SQL 自动调参”这两个关键词，基本会被判为“只用过本地 PostgreSQL，没真正踩过云上的坑”。

知识点

1. Cloud SQL 克隆本质：调用最近一次自动备份，在新实例上执行 PITR；新实例的 Tier（CPU/内存） 可以独立于源实例选择。
2. max_connections 的推导公式：Cloud SQL 为 PostgreSQL 实例维护一套 GAC（Google Auto Configuration） 模板，公式核心为
   max_connections = LEAST(用户显式值, 内存基准值)
   其中 内存基准值 ≈ RAM_GB * 100（官方未公开系数，经验值 80~120）。
3. 克隆时的“降配”场景：国内客户为了节省成本，常在克隆演练、开发测试环节把 4 vCPU 16 GiB 的源实例直接降到 2 vCPU 8 GiB，新实例内存减半，GAC 重算后 max_connections 自然下降。
4. 参数继承策略：Cloud SQL 只继承 用户显式 set 过的数据库标志位；如果源实例从未显式设置过 max_connections，则新实例完全以新规格为准，看上去就像“弄丢”了连接数。
5. 只读实例与克隆区别：只读实例强制继承主实例规格，因此不会出现该问题；克隆是独立实例，不受此限制。
6. 国内网络合规点：若源实例曾通过 私有服务连接（PSC）+ 自建 VPC 开启专用 IP，克隆后需重新绑定相同网络插件，否则连不上，但此点不影响 max_connections，面试时可主动提及以展示 “网络+参数”全局视角。

答案

克隆操作首先按备份时间点恢复数据，随后 Cloud SQL 会依据 新实例所选 Tier 重新计算推荐参数。max_connections 在 Cloud SQL 里属于 “受管参数”，其上限由内存规格直接决定：
新内存基准值 = 新实例 RAM_GB * 100
若克隆时把规格从 16 GiB 降到 8 GiB，基准值就从 1600 降至 800，系统再把用户之前显式设置的值裁剪到 800，于是出现“连接数变少”的现象。
结论：不是 PostgreSQL 本身丢失配置，而是 Cloud SQL 的自动调参机制根据新规格重新封顶，导致 max_connections 看起来“下降”。

拓展思考

1. 如何保持克隆实例连接数不变：先在源实例通过 gcloud sql instances patch 显式设置 max_connections=目标值，并选用 等于或高于源实例的 Tier 进行克隆；这样 GAC 不会把值裁低。
2. 生产环境灰度演练：国内金融客户常用 “规格对半砍” 做成本压测，可提前在 Terraform 模板 里把 tier 和 database_flags 同时变量化，保证克隆即合规。
3. 与 MySQL 差异：MySQL 的 max_connections 也受规格影响，但 Cloud SQL 给的系数不同，面试中若能横向对比，可体现 多引擎视野。
4. 未来趋势：Google 已在 Preview “自定义规格” 功能，届时内存与 CPU 可解耦，max_connections 的推导公式会更复杂，建议持续关注 Cloud SQL Release Notes 国内镜像站点，避免面试时被追问“下一步怎么优化”。