解读

面试官想知道你能否把“核数×8”这种线性直觉落地成可验证的数值，同时把 Cloud SQL 的共享存储架构、线程池模型、查询特征与Google 侧限流机制都考虑进去。国内面试场景里，直接回答“8 倍”会被追问“为什么是 8 倍”，答不出就减分；而给出“先压测再建模”又显得太空。正确姿势是：先给一条可复现的估算公式，再用Cloud SQL 内置指标把误差收敛到 30% 以内，最后交代边界条件，体现“能算又能兜底”。

知识点

1. vCPU 在 Cloud SQL 里对应 Intel Cascade Lake 的 Hyper-thread，1 vCPU=1 线程，而非完整物理核。
2. Cloud SQL 的存储层与计算层分离，QPS 天花板常先打在 CPU 侧的 InnoDB 线程并发或 PostgreSQL 的 spinlock，而不是磁盘 IOPS。
3. MySQL 默认 thread_pool_size 约等于 vCPU 数，PostgreSQL 默认 max_connections 与 vCPU 无关，需要手动调优。
4. Cloud SQL 有“最大并发查询”软限：MySQL 约 4 k、PostgreSQL 约 3 k，超过后会被 throttle。
5. sysbench 的 oltp_read_write 模型在国内互联网最常用的 10 张表 1 亿行数据集下，单 vCPU 大约产出 1.8 k QPS（MySQL 8.0）或 1.5 k QPS（PostgreSQL 13）。
6. Amdahl 定律：若 20% 查询串行，则 32 vCPU 理论加速比上限为 1/(0.2+0.8/8)=3.3 倍，而非 8 倍。
7. Cloud Monitoring 指标 cpu/utilization、database/mysql/insights/cpu_sql_ratio、postgres/insights/cpu_sql_ratio 可用来反推“可并行比例”。

答案

第一步：用 最近 7 天峰值时段的 Cloud Monitoring 数据 算出“可并行比例 P”。
公式：P = 1 – cpu_sql_ratio_max / 100。
举例：若 cpu_sql_ratio_max=75%，则 P=0.25，说明 25% 时间 SQL 在串行等锁。

第二步：代入 Amdahl 修正公式 得理论加速比 S。
S = 1 / [(1 – P) + P × (旧核数/新核数)]
= 1 / [0.75 + 0.25 × (4/32)]
= 1 / 0.78125 ≈ 1.28。
即 纯理论值只有 1.28 倍，远不到 8 倍。

第三步：用 sysbench 基线 把理论值映射到真实 QPS。
假设 4 vCPU 实测 7.2 k QPS，则 32 vCPU 预估 QPS = 7.2 k × 1.28 ≈ 9.2 k，提升比例约 28%。

第四步：加 Cloud SQL 限流校验。
MySQL 32 vCPU 实例软限 4 k 并发，若单连接平均 0.5 个活跃查询，则最大可持续 QPS≈4 k/0.5=8 k；9.2 k 已接近红线，需把 thread_pool_size 调到 64 并开启 innodb_thread_concurrency=0 才能吃到满收益，否则真实值会回落到 8 k，提升比例只剩 11%。

结论：在国内典型电商读写混合场景下，从 4 vCPU 升到 32 vCPU，QPS 提升比例预期 10 %–30 %；若业务能把串行锁优化到 P≥0.6，则有望拉到 3 倍，但绝达不到 8 倍。

拓展思考

1. 若实例已开启 Database Insights，可直接用“Top SQL”报表把 cpu_sql_ratio 拆到语句级别，定位哪条语句把 P 拉低，再决定是加索引还是拆表，而不是盲目加核。
2. Cloud SQL 的“独享型”机器（db-perf-optimized）在 32 vCPU 以上才给 25 Gbps 网络，若瓶颈其实在回包流量（如 SELECT * 大字段），升级前先把查询改成覆盖索引，可让同样硬件再多 20 % QPS。
3. 国内金融客户常要求双活，Cloud SQL 的跨区域只读副本延迟 80 ms+，若主库 CPU 降不下来反而拖高复制延迟，此时加核不如把读流量切到只读副本，QPS 总量可线性横向扩展，成本只有加核的 40 %。