Postgres大表问题
内容提要
Postgres大表会导致性能问题，如删除操作超时、复制延迟和停机。解决方案包括分区、垂直扩展和分片。分片将表分布到多个集群，解决真空延迟、备份慢、索引过多和宽表问题，并避免事务ID耗尽。分片是处理大表的最佳方案，但需选择正确的分片键。
延伸解读
分区与分片的取舍
分区能缓解大表问题，如降低真空触发阈值、加快备份和索引维护，但无法解决集群级限制，如事务ID耗尽和跨分区查询性能下降。分片将表分布到独立集群，隔离资源，使真空、备份和索引操作互不干扰，但需谨慎选择分片键，否则散射查询可能占用更多连接。
真空延迟的根源
大表真空问题源于触发阈值和完成时间。默认20%的触发比例在500万行表上需约100万死元组才启动，且真空期间与查询争用磁盘和缓存。分区可降低每分区触发阈值，但共享缓冲仍受限。分片则彻底隔离资源，使真空更快且不阻塞其他分片。
备份与恢复的瓶颈
大表备份耗时且可能阻塞事务。逻辑备份需长时间持有快照，物理备份复制整个堆和索引，恢复时间随表大小增长。分区不减少数据量，垂直扩展仅加速复制。分片将备份拆分为独立单元，恢复时间取决于最慢分片，而非最大表，显著提升效率。
索引与宽表的代价
大表需多索引，但索引增加磁盘占用、真空和备份负担。宽表触发TOAST和OID限制，更新频繁可能耗尽OID。分区可分散TOAST和索引，但文件数增多可能拖慢pg_database_size()。分片重置OID空间，减少索引影响，但无法解决行跨页问题，分区在fillfactor控制上更优。
Q&A
Postgres大表会导致哪些性能问题？
Postgres大表会导致删除操作超时、复制延迟、停机、真空延迟、备份慢、索引过多、宽表问题以及事务ID耗尽等性能问题。
Postgres大表导致复制延迟和停机的具体机制是什么？
当对大表执行级联删除时，删除大量行会生成大量WAL日志，导致网络和CPU饱和，使副本滞后。应用检查副本LSN，若副本未跟上，则所有读请求都发送到主库，主库同时处理写入和读取，最终导致停机。
Postgres大表有哪些解决方案？各自有什么优缺点？
解决方案包括分区、垂直扩展和分片。分区将大表按键值拆分为多个小表，有助于真空和查询，但跨分区查询可能变差。垂直扩展增加CPU、内存等资源，但只是临时缓解，不能解决根本问题。分片将表分布到多个集群，解决真空延迟、备份慢、索引过多和宽表问题，并避免事务ID耗尽，是处理大表的最佳方案，但需选择正确的分片键。
Postgres大表为什么会导致真空延迟？分区如何改善？
真空按表运行，大表真空耗时长，且触发阈值高（默认20%），导致真空启动晚。分区将大表拆分为多个小表，每个分区独立触发真空，阈值降低，真空可并行运行，从而改善真空延迟。
Postgres大表如何影响备份和恢复？分片如何改善？
大表使逻辑备份（pg_dump）长时间持有事务快照，物理备份复制大量数据，恢复时间随表大小增长。分片将备份和恢复拆分为多个小单元，可并行处理，恢复时间取决于最慢的分片，而非最大的表，从而显著加快备份和恢复。
Postgres大表为什么会导致索引过多？分片如何解决？
大表查询方式多样，为保持查询速度需添加大量索引，但索引占用磁盘、增加写入开销。分片将表分布到多个集群，每个分片上的索引更小，写入只更新所属分片的索引，因此可以创建更多索引而不会造成性能问题。
Postgres宽表（行宽或列多）会带来哪些问题？分片如何解决？
宽表可能导致TOAST表膨胀、OID耗尽、页填充率问题，以及pg_database_size()等操作变慢。分片将表分布到多个集群，每个分片有独立的TOAST表和OID空间，文件遍历按分片进行，从而缓解这些问题。
为什么说分片是处理Postgres大表的最佳方案？
分片将大表分布到多个集群，解决了真空延迟、备份慢、索引过多、宽表问题，并避免事务ID耗尽。每个分片是独立集群，资源隔离，查询更快，备份恢复更快，且能突破Postgres的硬性限制（如32位XID、TOAST OID）。
