提升AWS RDS PostgreSQL（db.t2.large）写入QPS性能的技术问询

针对你在AWS RDS db.t2.large实例上遇到PostgreSQL写入耗时过长的问题，结合你提供的my_test表结构，我整理了几个实战性的优化方向，按优先级排序如下：

一、先解决实例规格与存储的瓶颈 #

db.t2.large属于突发性能实例，它的CPU和IO性能依赖于信用积分，当积分耗尽后性能会骤降，非常不适合高写入的持续负载场景：

• 建议升级到db.m5/db.r5系列的通用型实例，或者如果是IO密集型场景，直接选择db.i3/io2/io2-blockexpress这类存储优化型实例，它们能提供稳定的持续性能。
• 检查当前RDS存储类型：如果用的是gp2，建议切换到gp3存储，可以独立调整IOPS（最高16000）和吞吐量（最高1000MB/s），避免gp2的IOPS随容量线性增长的限制，直接匹配你的写入需求。

二、调整PostgreSQL核心配置参数（通过RDS参数组） #

针对写入优化，重点调整以下几个参数：

• max_wal_size：默认值可能偏小（比如1GB），建议调至4GB-8GB（根据实例内存大小），减少checkpoint的触发频率——频繁的checkpoint会导致大量数据刷盘，严重影响写入性能。
• wal_buffers：增大到64MB或128MB（默认通常是16MB），让更多的写入操作先在内存的wal缓冲区里累积，再批量写入磁盘。
• synchronous_commit：如果你的业务可以接受极少量的数据丢失风险（比如允许主库故障时丢失最后几秒的写入），可以将其设置为off或local，这会跳过等待WAL写入磁盘的确认步骤，大幅提升写入速度。如果必须强一致性，保持默认on即可。
• shared_buffers：RDS默认会设置为实例内存的25%，你可以尝试调高到40%左右（不要超过实例内存的50%），让更多数据缓存到内存，减少磁盘IO。

三、优化写入操作的模式 #

单条写入的开销远高于批量操作，这是提升QPS的关键：

• 使用批量写入替代单条INSERT：
  • 对于小批量数据，用INSERT INTO my_test (test_index1, test_index2, json_dump, time_stamp, meta_info) VALUES (...), (...), (...);的形式，一次插入几十到上百条数据（注意不要超过PostgreSQL的单语句长度限制）。
  • 对于大批量数据，优先使用COPY命令，它的写入效率比INSERT高一个数量级，适合批量导入场景。
• 合并事务：将多个写入操作放在同一个事务中执行（比如BEGIN; INSERT ...; INSERT ...; COMMIT;），减少事务提交的开销——每次事务提交都需要刷WAL到磁盘，合并后能大幅降低磁盘IO次数。
• 避免不必要的写入：检查是否有重复写入的场景，比如可以先通过主键判断记录是否存在，再决定是否插入，减少无效的写入操作。

四、针对表结构与索引的优化 #

你的表主键是复合text类型，这会带来一定的写入开销：

• 优化主键类型：text类型的主键索引体积较大，写入时维护索引的开销更高。如果test_index1和test_index2可以转换为更紧凑的类型（比如整数、UUID或者短字符串），建议替换——比如用UUID的话，注意使用uuid_generate_v1mc生成顺序UUID，避免索引碎片问题。
• json_dump字段选型：你当前用的是json类型，它比jsonb的写入速度更快（因为不需要解析和格式化存储），如果不需要对json内容进行查询或索引，保持json类型即可；如果需要查询，再考虑换成jsonb，但要接受写入性能的小幅下降。
• 避免冗余索引：目前你的表只有主键索引，这是最优的状态——额外的索引会在写入时增加维护成本，除非必要不要添加。

五、AWS RDS专属优化选项 #

• 调整复制模式：如果开启了多AZ部署，默认是同步复制，会等待备库确认WAL写入。如果业务允许，可以切换为异步复制，减少主库的等待时间。
• 使用Performance Insights定位瓶颈：在RDS控制台开启Performance Insights，查看等待事件（比如checkpoint_write、wal_write、buffer_io等），精准定位是CPU、IO还是内存导致的写入瓶颈。
• 考虑迁移到Aurora PostgreSQL：Aurora采用共享存储架构，WAL写入效率远高于原生RDS PostgreSQL，能提供更高的写入吞吐量和更低的延迟，适合高写入负载场景。

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