解读

在国内云厂商面试中，这道题考察的是“对 Cloud SQL 资源隔离与容量模型是否真正理解”。
很多候选人只背过 MySQL 参数，却说不清 Google 在托管层额外扣掉了多少连接、扣给谁、对业务有什么实际影响。
面试官想听到的是：

1. 你清楚 Cloud SQL 实例规格 ↔ 内存 ↔ max_connections 的映射公式；
2. 你知道 Google 会预留 50 条超级连接（system reserved）做健康检查、备份、故障切换，业务永远拿不到；
3. 你能区分 max_user_connections 是单 Google 账号维度，而 max_connections 是实例总上限，两者叠加后业务真实可用连接数还要再减 50；
4. 你能给出 国内客户最常踩的坑：用 root 账号做连接池，结果把 max_user_connections 打满，导致监控探活失败触发重启。

知识点

1. max_connections：Cloud SQL 根据 实例内存 = (GB) × 100 + 50 计算，最小 250，最大 60000；内存扩容 1 GB 直接带来 100 个连接额度。
2. max_user_connections：单 Google 身份（email 或 service account）可同时持有的连接上限，默认等于 max_connections，但可在控制台或 flags 里单独调小，用来做 业务账号隔离。
3. system reserved：Google 后端用 cloudsqladmin、cloudsqlagent、cloudsqlreplica 三个内部账号各占用约 16–17 条连接，合计 50 条永不释放；业务侧 show processlist 看不到，但计算剩余额度时必须先减 50。
4. 真实可用连接数公式：
   available = min(max_connections – 50, max_user_connections)
   若实例 4 GB，则 max_connections=450，available=400；若你把 max_user_connections 设为 200，则 available 进一步被裁成 200。
5. 国内合规要求：等保 2.0 要求“数据库资源应可按账户粒度限制”，max_user_connections 正是 Google 提供的原生手段，无需额外装插件即可过测评。

答案

“在 Cloud SQL 中，max_connections 由实例内存按‘每 GB 100 条 +50’自动算出，代表实例总连接上限；max_user_connections 是单个 Google 身份可同时打开的连接数，默认等于 max_connections，但可单独下调，用于业务账号级限流。Google 后端为健康检查、备份、主从切换预留了 50 条系统连接，这部分对业务不可见也永不释放。因此，业务真实可用连接数 = min(max_connections – 50, max_user_connections)。例如 4 GB 实例 max_connections=450，若 max_user_connections 保持默认，则业务最多同时用 400 条；若把某个微服务账号的 max_user_connections 设成 100，则该账号只能开到 100，其余账号可继续用到 300，既满足等保账户粒度限制，也避免单应用把连接池打满导致监控探活失败。”

拓展思考

1. 高并发场景：国内电商大促常把实例临时升到 32 GB，max_connections 变成 3250，可用 3200；结束后立刻降配，连接池要同步收缩，否则业务侧会出现“MySQL 报错 1040，但监控显示连接数远未到上限”的诡异现象，其实就是忘了降配后可用连接已变 3200→400。
2. Private IP + VPC-SC：在金融云合规方案里，system reserved 连接同样走 Private IP，但流量不走客户 VPC，而是走 Google 内部 Servicenetwork，因此客户防火墙无需放行这 50 条连接，也不能通过 flow log 看到，面试时可作为“Google 托管层如何做到零信任隔离”的加分点。
3. 连接池参数建议：国内用 Spring Boot + HikariCP 的项目，建议把 maximum-pool-size 设为 available × 0.8，留下 20% 给监控及突发；同时把 max_user_connections 下调到 pool-size × 1.2，既防止单应用占满，又留一点余量给热升级。