前言:

本人使用postgresql数据库已有若干年了,postgresql数据库和MySQL以及Oracle数据库,达梦数据库,高斯等等数据库都有很多开发和使用经验,但最近几年来说,侧重于postgresql数据库的开发和使用。那么,什么是数据库维护?为什么选择postgresql数据库?MySQL和postgresql数据库性能对比有哪些?postgresql数据库到底好在哪,又有什么明显的缺点呢?

我想,就以上的问题,在本文做一个总结,做一个汇总;把这些使用经验尤其是postgresql数据库的使用经验与各位同学做一个分享,以期达到大家的共同进步,如有错漏,欢迎各位大佬指教。

一、

什么是数据库维护?

数据库维护相对数据库的生命周期来说,主要是指的数据库部署后,对该数据库的维护治理工作,其中包括数据库的性能调优,也就是数据库的性能释放;数据库系统的插件系统的扩展和维护,例如,postgresql数据库的pg_stat_statements(更全面的数据库系统监控插件),pg_profile(基于pg_stat_statements的awr报告生成插件),pg_trgm(索引插件),pg_repack(在线表膨胀治理工具)等等插件的部署和使用维护;数据库数据抽取和迁移;数据库索引维护(比如,数据库过多索引的清理,缺少索引的补漏);数据库数据治理(例如,重复数据维护);数据库的灾备系统建立等等这些工作都可以算做数据库维护的范畴

按其他人的说法,我是比较认可下面这些理论的:

1. 备份与恢复备份与恢复是数据库维护的核心任务之一,旨在防止数据丢失并确保灾难发生时能快速恢复。通过定期执行全量备份(完整数据拷贝)和增量备份(仅备份变化部分),结合制定明确的恢复策略(如时间点恢复、多副本冗余),可最大限度降低数据丢失风险。例如,金融行业通常要求备份保留周期覆盖业务审计需求,同时通过异地容灾架构提升恢复可靠性。

2. 性能监控与优化实时监控数据库资源使用情况(如CPU利用率、内存占用、I/O吞吐量)是性能优化的基础。通过工具(如AWR报告、慢查询日志)定位性能瓶颈后,可针对性优化查询语句(避免全表扫描)、调整索引策略(如复合索引设计)或优化数据库配置参数(如缓冲池大小)。例如,电商系统在促销期间需动态调整连接池数量以应对高并发请求。

3. 安全管理安全管理涵盖用户权限分级、访问控制与日志审计。通过角色基于权限管理(RBAC)限制敏感数据访问,结合审计日志追踪异常操作(如未授权登录、数据导出),可有效防范内部泄露与外部攻击。例如,医疗数据库需符合HIPAA等法规要求,对患者信息实施加密存储与细粒度权限控制。

4. 数据完整性维护通过主键/外键约束、唯一性约束、CHECK约束等机制确保数据逻辑正确性,同时利用触发器实现复杂业务规则(如订单状态变更时自动更新库存)。例如,银行交易系统需通过事务机制保证资金转移的原子性,避免数据不一致。

5. 日志与空间管理日志管理包括错误日志分析(定位事务故障、死锁)与操作日志追踪(用于合规审计),而空间管理需定期清理冗余数据(如临时表、过期日志)、重组索引碎片并扩展存储容量。例如,物联网平台需处理海量传感器数据,需通过分区表与归档策略控制存储成本。

6. 索引与参数调优索引维护需定期重组(解决索引碎片)或重建(修复损坏索引),参数调优则根据业务负载动态调整(如Oracle的SGA大小、MySQL的innodb_buffer_pool_size)。例如,社交媒体应用在用户增长期需优化索引以支撑快速查询。

7. 软件更新与容量规划及时应用数据库厂商发布的补丁可修复安全漏洞,容量规划则需预测数据增长趋势(如用户量、交易量),提前扩展硬件资源(如存储阵列、计算节点)。例如,云计算平台需通过弹性伸缩架构应对突发流量。

二、

MySQL和postgresql数据库的全面对比

MySQL数据库和postgresql数据库两者同为关系型数据库,两个数据库孰优孰劣一直是一个比较有争议的话题。其实,文无第一,武无第二,很明显的,数据库是在文这里面的。如果这个数据库能够契合你的业务,能够满足你当前的需求,那么,这个数据库就是好的;反之则不是,就这么一个简单的逻辑。

ok,现在我通过以下一些维度将两个数据库做一个详细的对比。

1、性能方面

当一个业务系统使用人数不高,这个范围通常是 1 2千人,且并发请求不高时那么毫无疑问的,MySQL数据库和postgresql数据库性能应该相差不大。

如果是高并发的业务系统,那么,后台数据库的第一选择应该是postgresql数据库,主要是postgresql数据库的并发优化设计做的比MySQL更好,但,需要指出的是,postgresql数据库的高并发是牺牲了一些易用性的,主要是体现在运维难度高,学习曲线比较陡峭。

本人曾经压测过一个postgresql-12版本的数据库,在极端压测环境下,cpu负载短期内达到200多仍然是稍显缓慢,但cpu负载在260左右的时候,cpu和内存双双崩溃;而MySQL数据库我相信是做不到这么高的高并发负载支撑,换言之,postgresql数据库的数据吞吐率(QPS)是很高的,在实际使用中,可以明显感受到postgresql数据库的吞吐率远远没有达到极限(也就是性能怪兽并不是完全释放,即使调优后也仅仅达到了完全性能的百分之90左右

总结:如果是高并发系统,或者中短期的未来,业务系统可能会成为高并发,那么,选择postgresql无疑是正确的,只是需要面对未来的复杂运维这一局面。

2、安全性方面

MySQL数据库和postgresql数据库两者各有千秋,但postgresql数据库显然安全性方面应该是更高的,比如,连接安全,用户安全,灾备安全方面,postgresql数据库的选择也是明显的更多。

数据安全层面,严格的ACID特性、强大的MVCC机制和行级安全性(RLS),postgresql数据库通常是更值得信赖的选择。

数据灾备安全层面,postgresql数据库由于是开源项目,因此,有更多的,可以让人挑花眼的选择,例如,pg_dump,pg_basebackup,pg_backrest,pgram等等大概接近20种的选择,而MySQL的灾备方式大概只有四五种,不得不说,postgresql数据库对于选择强迫症人士来说,是非常不友好了(postgresql数据库可选择太多,也会带来一些试错成本,运维复杂度)

总结:安全性方面来说,postgresql数据库是完胜MySQL数据库的

3、易用性方面

MySQL数据库和postgresql数据库两者基本都是开箱即用,就是说,两者都能快速部署,快速应用

总结:从易用性方面来说,两者相差不大

4、可用性方面

可用性指的是系统能够正常运行的时间的比例,postgresql数据库的读写性能这些是明显比MySQL数据库高的,也就是说,在高流量的冲击下,postgresql数据库的可用性肯定是比MySQL数据库高几个量级

5、可靠性方面

可靠性是指的系统在应用或者系统错误面前,在意外或者错误使用的情况下,维持软件系统功能的特许的基本能力,postgresql数据库比MySQL数据库是更好的,具体体现在postgresql数据库的幻读,重复读,丢失修改概率相比MySQL数据库来说更少,也就是高并发支撑更优秀,锁机制更为精细和复杂

总的来说,PostgreSQL 的锁机制设计得更为精细和复杂,与其强大的 MVCC 紧密结合,在读写混合的复杂场景下通常能提供更好的并发性能。MySQL (InnoDB) 的锁机制相对直观,在简单查询和特定隔离级别下能有效工作,但需要开发者更关注索引设计和 SQL 优化以避免意外的锁冲突。

总结:postgresql数据库比MySQL数据库可靠性方面显然更优

6、功能性方面

postgresql数据库可以用作缓存数据库,图形数据库,地理数据库,大对象存储数据库,关系型数据库等等,可以称之为数据库里的瑞士军刀

功能特性

PostgreSQL

MySQL

SQL标准兼容性

极高,严格遵循SQL标准,实现严谨

良好,但更为灵活,会对特定语法进行扩展

数据类型丰富度

非常丰富。支持数组、JSONB、HSTORE(键值对)、IP地址、几何类型等

基础。提供常规类型,后期加入了JSON支持

索引类型

多样化。除B-Tree外,支持GIN(全文搜索/JSON)、GiST(地理数据)、BRIN(大数据集)等

以B-Tree为主。满足大多数场景,近年来增加了倒排索引等功能

复杂查询能力

强大。优化器更先进,对复杂连接、CTE(包括递归CTE)、窗口函数支持完善

持续增强。能够处理常见复杂查询,但在非常复杂的子查询和连接方面可能稍逊一筹

数据完整性与ACID

严格。支持强大的外键、检查约束,提供可靠的事务保证

良好(InnoDB引擎)。支持事务和外键,但默认配置可能在某些方面(如约束检查)相对灵活

扩展性

核心优势。支持通过扩展(如PostGIS)添加地理空间功能,有FDW(外部数据包装器)查询其他数据源

通过存储引擎插件。如MyISAM(读多写少)、Memory(内存表)等,但InnoDB已成为绝对主流

复制与高可用

物理复制(流复制)为主,一致性高、性能好;也支持逻辑复制

逻辑复制(基于binlog),灵活性强,生态成熟

总结:在功能性方面,很明显,postgresql数据库完胜MySQL数据库

三、

postgresql数据库的明显优势

优势维度

核心亮点

📊 标准兼容与数据完整性

严格遵循 SQL 标准,提供强大的 ACID 事务支持和丰富的数据类型/约束机制 

🧩 高级功能与可扩展性

支持高级数据类型(如 JSONB、数组),提供 GIN、GiST 等多种索引,允许通过扩展(如 PostGIS)添加新功能 

🛡️ 数据可靠与复制

采用多版本并发控制(MVCC),基于 WAL 的物理复制保障数据一致性和高可用性 

🚀 复杂查询性能

优化器先进,支持复杂表连接、并行查询、窗口函数等,擅长处理复杂分析和大规模数据 

🌐 跨平台与生态系统

支持多种操作系统和编程语言,拥有强大的开源社区和丰富的第三方工具

四、

postgresql数据库的明显缺点

相比于一些数据库,PostgreSQL 可能需要更多的调优和维护知识。

第一、postgresql数据库的膨胀问题

例如,其多版本并发控制(MVCC)机制虽然提升了读并发性能,但也可能带来存储空间需要定期通过 VACUUM等操作进行维护的考虑

其实这个存储空间,也就是表膨胀,索引膨胀,wal日志膨胀这几个膨胀对于运维工作来说,是非常不友好的

表膨胀和索引膨胀对于postgresql数据库的性能来说,影响是非常巨大的,并且这两个膨胀是没有限制的,也就是说,如果发生了表膨胀而你并没有对此做任何处理,那么,表体积将会是无限增长的

在我的实际工作中,有些表体积膨胀了2w余倍(单表处理压缩前70余G,处理压缩后十几M),当然,造成的后果是非常惨重的,数据库查询性能下降(这个查询性能下降是缓慢的,非指数级别)倒还是在其次的,主要是引发数据库的资源消耗加剧,磁盘空间就不说了,宝贵的cpu和内存资源几近耗尽。

当然,确实有对这些问题的忽视因素,但我想说明的是表膨胀,索引膨胀是无限的,对读写性能不是指数级的,也就是说读写通常在可忍受范围,但不在可接受范围;对于cpu和内存资源来说,也会引发越写越慢,越慢越写的额外不可控负担,最终导致一个严重的后果。

wal日志膨胀可以通过关闭,定时脚本清理等手段来处理,但无疑的,这些是会降低整个数据库系统的安全性,也就是说,wal日志膨胀是我们一个需要考虑的敏感点:安全性是否应该牺牲系统的存储性能?

第二、postgresql数据库的版本问题

其次,是postgresql数据库的版本众多,新旧版本变化比较大,学习曲线是比较陡峭的

postgresql数据库没有代表性的,经典的那种版本,不像MySQL数据库有经典的mysql5.7版本,Oracle有11g版本,这些版本问题导致在架构设计阶段,可能会有很多迷茫。

第三、postgresql数据库的调优标准问题

最后,是postgresql数据库的参数调优方面,由于是开源项目,因此,很多地方是没有定论的,比如work_mem这个参数,有很多种建议,有建议64M的,有建议32M的,甚至有建议1个G的,但同时每个人都说要根据自己的实际硬件情况来确定,可是却没有一个固定的测算标准,完全就是根据自己的实际经验来设定。

我这里想说明的是,postgresql数据库确实很好,但我们如果只使用默认参数来进行系统设定,这固然是可以用,但我们调整优化的目的却非常难以实现;没有什么固定的标准,最终会导致我们的数据库系统只是一个平庸的系统,而不能完全发挥出postgresql的所有性能。

总结:如果postgresql数据库能够彻底解决表膨胀,索引膨胀,wal日志膨胀问题 以及调优参数设定困难这些细节问题,那么,postgresql数据库必定是世界第一数据库。

postgresql数据库真的是一款非常优秀的关系型数据库,但如果想用好,是真的需要付出更多的耐心和智慧。

Logo

北京人形旗下天工造物具身智能开源社区,聚焦具身天工与慧思开物两大平台

更多推荐