如何提升Google Cloud SQL的每秒查询数（QPS）？

我之前也碰到过类似的跨区域Cloud SQL性能瓶颈问题，结合你的情况给你几个实操性强的方案，从快到慢、从易到难排序：

• 用私有IP+Cloud VPN降低延迟：越南到新加坡的公网延迟大概30-50ms，这是拖垮QPS的核心原因之一。你可以给Cloud SQL开启私有IP，然后在本地机器和新加坡VPC之间搭建Cloud VPN（免费额度足够小流量使用），用私有IP访问SQL服务器，延迟能降到10-20ms左右，QPS至少能提升20%-30%。免费层级的Cloud SQL支持私有IP，在控制台就能直接配置。
• 开启查询缓存：如果你的查询有大量重复的只读请求，开启查询缓存能直接跳过磁盘IO，从内存返回结果。以MySQL为例，8.0版本默认关闭缓存，你可以通过SHOW VARIABLES LIKE 'query_cache%';查看状态，然后在Cloud SQL参数设置里把query_cache_type设为1，query_cache_size设为64M左右（别太大，避免内存浪费）。PostgreSQL也有类似的pg_prewarm插件可以预热常用数据到内存。
• 用连接池替代短连接：本地应用别每次查询都新建TCP连接，用连接池（比如Python的SQLAlchemy连接池、Java的HikariCP）保持长连接，减少跨区域TCP握手的开销——这部分延迟在跨区域场景下占比极高，优化后能明显提升并发请求数。

如果网络优化后还是不够，可以只迁移高频查询的核心逻辑，不用动整个本地应用：

• 用Cloud Run部署查询服务：把频繁发SQL请求的代码打包成Docker镜像，部署到新加坡区域的Cloud Run。Cloud Run是serverless服务，免费额度足够测试，按实际使用付费。这样核心查询模块和SQL同区域，延迟几乎为0，QPS能直接拉上去；本地应用只需要通过HTTP/GRPC和Cloud Run通信，非高频请求的跨区域延迟影响可以忽略。
• 用Cloud Functions处理批量查询：如果是批量重复的查询任务，把查询逻辑写到Cloud Functions里，本地应用通过HTTP或Pub/Sub触发函数执行，函数在新加坡区域直接访问SQL，批量返回结果，减少单次请求的往返次数，提升整体QPS。

• 排查慢查询：在Cloud SQL控制台开启慢查询日志，找出耗时超过1秒的查询。比如你反复发送的查询如果是SELECT * FROM table WHERE user_id=?，那user_id字段一定要加索引——没索引的全表扫描会直接拖垮免费层级的CPU资源，QPS自然上不去。
• 本地缓存重复请求：如果应用会反复发送相同的查询（比如查询固定配置、热门数据），先在本地用内存缓存或Redis做一层缓存，不用每次都请求Cloud SQL。比如把热门数据缓存5分钟，能减少大量无效的SQL请求。

免费层级的Cloud SQL只有1vCPU和0.6GB内存，资源本身就有限。如果上面的优化都做了还是达不到需求，可以升级到最低的标准层级（比如db-f1-micro），CPU和内存翻倍，QPS能轻松到200+，每月费用也就几美元；如果搭配同区域部署，标准层级的QPS能冲到500+，完全能满足大多数中小应用的需求。

内容的提问来源于stack exchange，提问作者user4079032