仅支持追加写入的表可做哪些RDBMS优化？（以PostgreSQL、MySQL为例）

事务隔离级别调整可行性 #

首先可以明确：完全可以使用更宽松的事务隔离级别，不会产生业务一致性风险。因为这类表仅支持INSERT和SELECT，无UPDATE/DELETE操作，已写入的旧行永久不变，不存在行修改导致的读写冲突，也不会出现脏写、不可重复读问题，即便是出现传统定义下的幻读，对事件类业务也不会产生数据一致性影响，因此可以大幅降低事务隔离级别，减少数据库锁、MVCC可见性判断的开销。

PostgreSQL 隔离级别适配 #

• 可以直接将读写该表的事务隔离级别设置为读未提交（Read Uncommitted），PostgreSQL的MVCC实现决定了读未提交级别也不会读到其他事务未提交的脏数据，和读已提交的一致性保证几乎一致，但可以减少部分事务状态判断的开销，性能优于默认的读已提交级别。
• 无需使用可重复读、可串行化等高隔离级别，完全没有必要。

MySQL 隔离级别适配 #

• 如果业务允许极小概率读到最终回滚的未提交事件（比如监控、日志类非核心事件），可以直接设置为读未提交（Read Uncommitted），相比默认的可重复读级别，可以完全避免gap锁开销，插入性能提升30%以上。
• 如果业务要求必须读取已提交的事件，仅需设置为*读已提交（Read Committed）*即可，无需使用默认的可重复读级别，同样可以避免gap锁导致的插入阻塞问题，性能提升明显。

其他可落地优化方案 #

通用优化 #

• 索引优化：主键优先使用自增ID、时序ID等有序值，避免随机写入导致的索引分裂，二级索引按需创建，仅追加表的索引维护开销远低于可更新表，但多余索引依然会拖慢写入速度。
• 批量写入：优先使用批量INSERT语法，比如INSERT INTO event_table (col1, col2) VALUES (v1, v2), (v3, v4)...，相比单条插入性能可提升数倍。
• 时序分区：按事件生成时间做表分区，查询时可以直接剪枝不需要的分区，大幅提升查询效率，旧分区永久不会修改，可以直接设为只读状态减少管理开销。
• 冷数据归档：超过保留周期的冷数据可以直接删除对应分区或者导出归档，避免单表数据量过大导致的性能下降。

PostgreSQL 专属优化 #

• 关闭自动垃圾回收：仅追加表不会产生死元组，autovacuum运行没有实际价值反而占用资源，可以执行ALTER TABLE event_table SET (autovacuum_enabled = false);关闭该表的autovacuum。
• 无日志表优化：如果数据允许少量丢失（比如非核心监控日志），可以创建无日志表：CREATE UNLOGGED TABLE event_table (...)，写入性能比普通表高30%以上，因为不需要写WAL日志，缺点是实例崩溃时会丢失未刷盘的数据，只读副本不会同步该表数据。
• 调整填充因子：普通表默认fillfactor为90，预留10%空间用于UPDATE操作，仅追加表无需预留，可以设置为100：ALTER TABLE event_table SET (fillfactor = 100);，完全利用页空间，节省存储的同时提升读写性能。
• 并行查询优化：可以单独为该表设置更高的并行查询worker数：ALTER TABLE event_table SET (parallel_workers = 4);，大查询时可以利用多CPU核心提速。

MySQL 专属优化 #

• 调整填充因子：InnoDB默认innodb_fill_factor为80，预留20%空间用于UPDATE，仅追加表可以将该参数调整为100，节省存储空间，提升写入性能。
• 关闭Change Buffer：仅追加表的二级索引写入都是追加操作，不需要修改旧索引页，Change Buffer没有发挥空间反而增加开销，如果实例中大部分是这类表，可以将innodb_change_buffer_max_size设置为0。
• 高写入场景参数优化：如果允许少量数据丢失，可以将innodb_flush_log_at_trx_commit设为2，sync_binlog设为0，写入性能可提升数倍，缺点是实例崩溃时会丢失最多1秒的未刷盘数据。
• 冷数据转ARCHIVE引擎：不需要修改的旧分区可以转成ARCHIVE引擎，该引擎专门为仅追加的日志类场景设计，压缩比可达1:10以上，大幅节省存储空间，查询性能满足冷数据低频访问需求。

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