GCP Cloud SQL Postgres实例插入数据极慢问题排查

你遇到的本地数秒、远端数小时的性能差，本质是单条循环插入的线性开销在高延迟链路+低配云实例上被极度放大，具体原因按影响权重从高到低排列：

• SQL Auth代理+网络链路的延迟放大
  通过SQL Auth代理连接时，每执行一条INSERT都要完成一次完整的客户端→代理→数据库→代理→客户端的网络往返。本地连接数据库的RTT（往返延迟）通常在0.01_{0.1ms级别，20万条单条插入的总网络开销不到20秒；如果脚本运行环境和GCP实例跨可用区、跨区域，或者走公网连接代理，RTT很容易达到20}100ms，光等网络往返的总耗时就会达到200000*0.05s=10000秒（约2.8小时），和描述的数小时耗时完全吻合。如果链路存在丢包触发TCP重传，耗时还会进一步升高。
• 基础规格Cloud SQL实例的硬性能瓶颈
  GCP基础规格Postgres属于共享资源实例：CPU和其他租户共享，有严格的限流阈值；配套的持久化磁盘IOPS上限极低（通常只有几百），且默认不开启写入缓存。本地测试用的数据库通常跑在本地SSD上，IOPS可达数万，CPU为独占资源，单条写入的执行和刷盘延迟本身就比云基础规格实例高几十到上百倍。此外Cloud SQL默认会运行监控采集、日志上报、备份校验等后台进程，会进一步抢占本就有限的CPU和IO资源。
• 单条循环插入的写法放大了所有开销
  即使所有插入在同一个事务中，如果你在循环中逐次调用cursor.execute()执行单条INSERT语句，没有使用executemany()批量接口或者多值INSERT语法（INSERT INTO table VALUES (v1), (v2)...），每一条语句都会单独经历网络传输、SQL解析、执行、结果返回的全流程。这种写法在本地低延迟环境下感知不到明显开销，但在远端低性能实例上，总开销会随插入条数线性累加，直接差出几个数量级。
• 数据库配置与表结构的差异
  本地测试环境的Postgres往往会关闭fsync、设置synchronous_commit=off来提升测试速度，插入不需要等磁盘刷盘完成就可以返回；而Cloud SQL默认强制开启持久化配置，单条插入必须等数据落盘才会返回响应。此外如果GCP上的表配置了多个二级索引、外键约束、行级触发器，单条插入的计算开销本身就会比本地无额外约束的测试表高很多。

快速排查方向：优先将脚本部署到和Cloud SQL实例同区域的VPC内主机上运行，排除公网/跨区延迟影响；将单条循环插入改为每500~1000条一组的批量写入，正常情况下20万条记录的插入即使在基础规格实例上也能在几十秒内完成；同时查看Cloud SQL监控面板的CPU使用率、磁盘IO等待指标，确认是否触发了资源限流。

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