1),PG的事物xid为32位,可用事物xid大概有21亿多,有些较老的小版本有bug、可能会导致DB要单用户模式做vacuum freeze,影响业务可用性,另外对于无bug的版本也最好添加自定义vacuum freeze任务来避免事物id耗尽。(亲身经历)
2),对大表加字段时同时加默认值,会上排他锁,重写数据,导致表不可用。PG11版本前
3),更改数据类型,除了varchar扩容长度的都会重写数据,上排它锁,导致表不可用。
4),PG delete删除一般不释放磁盘空间给操作系统,只能复用这些空间,最好改造成分区表,通过truncate历史分区这样可以释放磁盘空间。
5),PG频繁delete/update会造成表和索引膨胀,频繁delete/update会导致索引效率不高,可能产生慢查询甚至故障,需要定期重建索引或者分表。
6),PG的逻辑复制在12版本前,如果复制槽状态为f,长时间积压wal,可能导致主库磁盘崩掉,启用逻辑复制时需要监控复制槽状态和主从延迟差异。
7),熟悉PG的开发相对较少,沟通成本稍微偏大,要定规范,多培训研发或者客户。
8),由于PG 的MVCC机制,需要定期vacuum和analyze,可能需要针对大库/表调整autovacuum/analyze等参数因子,否则可能执行计划不准,导致慢查询。
9),PG生态虽说在不断完善,但总体和mysql相比还需要继续发展和提高,还有大量的空间待提高。
10),PG专业人才相对来说比较匮乏,和MySQL等相比还是较少,不过国内现在PG人才培养机制在不断发展和完善,专业的事情交给专业的人来做才是性价比最高的,如果大家有需求也可以直接在下面评论区联系我。
本文暂时没有评论,来添加一个吧(●'◡'●)