PostgreSQL 现世报，客户吐槽不如SQL SERVER 与国产数据库搞兼容性

原创于 2025-12-10 06:00:58 发布 · 452 阅读

CC 4.0 BY-SA版权

文章标签：

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

问题

最近六群问题多，都让徐老师费心了，最后我结尾说写一篇，但我的从PostgreSQL的角度来写，因为其实这个国产数据库我就认为他是PG。为了不被一些其他的数据库友商，利用，注意这个词，利用对这个国产数据库产生不良的影响，我把名字都画红了。

别问是那家，问就是你们家的！！！

首先我们要明白，一个数据库的使用，替换他是有门道的，不是说数据库兼容性100%，从Oracle,或者迁移过来到国产数据库只要语法跑通，那就行。

NO NO NO，我们今天就以这个问题为例，来说说兼容性迁移的问题。

因为在这个同学的问题中，提出了一个关键的前摄，以前他的这些程序在MSSQL，也就是我们的SQL SERVER跑的挺好的，尤其在AlwaysOn上并不存在他现在在PG上所存在的一些问题，也就是从库基本上无法从事辅助查询的工作，从库成为了摆设，那么咱们先回顾一下，之前为什么在MSSSQL上是可以的，。

---MSSQL 数据节点之间数据传输的原理

Log Writer线程：当任何一个SQL用户提交一个数据修改事务时，它会负责把记录本次修改的日志信息先记入一段内存中的日志缓冲区，然后再写入物理日志文件（日志固化）。

Log Scanner工作线程：位于主副本所在SQL Server上。这个线程专门负责将日志记录从日志缓冲区或者日志文件里中读出，打包成日志块，发送给各个辅助副本。由于它的不间断工作，才使主副本上的数据变化，可以不断地向辅助副本上传播。

固化（Harden）线程和重做（Redo）线程：位于辅助副本所在的SQL server上。固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本的磁盘上的日志文件里（这个过程被称为"固化"）。而重做线程，则负责从磁盘上读取日志块，将日志记录翻译成数据修改操作，在辅助副本的数据库上完成。

这些线程在工作上各自独立，以达到更高的效率。Log Scanner负责传送日志块，而无须等待Log Writer完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据已经传递完毕，而无须等待重做完成。其设计目标，是尽可能地减少AlwaysOn所带来的额外操作对正常数据库操作的性能影响。

之前我也写过SQL SERVER ALWAYS ON 为什么无法dump日志，https://cloud.tencent.com/developer/article/1596430，不熟悉这块的可以看看。

ldf MSSQL日志

这么说吧，MSSQL的日志，比POSTGRESQL的日志设计那是要好很多的，且设计的很精妙。物理的日志，物理的数据传输到从节点，然后硬化到MSSQL的从节点日志，然后REDO重做，速度不能说非常快，只能说不输给ORACLE。

可为嘛到了POSTGRESQL 他就不行了，这和国产数据库无关，因为这个国产数据库他也是复刻了PG的原理。我们来数落一下PG在这块的问题。

1 数据中存在太多 FPW，这个懂的都懂，我们也做过此时PostgreSQL为了防止突然断电，而让数据库的日志承受了太多的无用的，页面数据，也就是PG的日志不是日志，是一部分数据PAGE+日志，日志中只有30%左右是真正的日志，这个我们做过测试，剩下的70%都是为了断电保护而留存的数据页面。

那么，PostgreSQL就有大量的无效数据在日志中，这些东西，要传输，要到从库，你还要读WAL，然后还要通过WAL进行重做。

那么PG就必须慢，必须性能不好，这不明摆的事情。

2 数据的单线程的读

是的在从库接受到日志后，这个读取接收日志的线程是单线程的，也就是如果你此时有大量的事务，到了从库，他只有一个人干活，他叫wal receiver,而更有意思的在后面，他的挖了applier 回放的也是单线程。（提一句PG17是多线程了）有对数据库物理复制着急的，你的用PG17及以上的PG数据库那能解决你一些问题。

写到这里了，有人说那我怎么办，怎么办？

1 选择数据库内核在PG17以后的PG版本，性能会好

2 国产数据库，也尽量问一下他们的这个产品基于PG的这个部分，是否自我改造成多线程的wal applier。

那么不幸，这个同学的国产数据库，版本呢，一定是很低的，所以，我还说吗？

那么解决方案

1 如果必须要从库查询，可以抛弃物理复制的部分，我们直接用PG提供的逻辑复制槽来解决问题。

为什么PG是提供逻辑复制的，也就是你可以选择你想使用的表，比如100张表里面有50张表是你要分担查询压力的，你直接就做逻辑复制槽，然后把这些数据放到你的“从库”，然后在从库上查询来缓解PG主库的压力，当然这里注意PG的逻辑复制槽是异步的，他不是和MSSQL一样是同步或提供主从同步的功能哟。

2 如果你接受不了逻辑复制槽，必须要在物理复制槽上动手脚，哪里你就选择PG的同步数据功能，当然这样性能一定会变差，拖累主库，因为你的一个事务只有在从库被commit后，你的主库才能commit，所以选择这个部分的话，你的网络，你的从库的性能一定要好，超级的好，超级的稳定。

这样会能解决你，主库写入，从库抱怨查不到的问题。但你又出现新的问题，数据库性能低。

写到最后，我觉得有必要说一些国产数据库尤其是基于PG开发的数据库产品，请不要再做什么兼容性了，咱们这些问题解决不了，你兼容性做的越高，你的产品越失败，因为语法的兼容都是假的，会露馅的，会倒台的，语法兼容后，用户会认为你和商业数据库的性能一致，剩下的你就等着吐槽，然后更换你吧！你连第二次活的机会都没有，小媒体在给你一传，你就等死吧！

你不如解决这些痛点的问题，然后和那些假冒伪劣国产数据库划清界限，谁是假李逵，谁是真李逵这不马上现世报！

这就是，竹板这么一打，国产DB现世报，做了语法兼容抢市场，到头一场空，客户以为你能行，其实你是嘛也不行，除了语法能兼容，其他显眼散德行！！！

PostgreSQL 现世报，客户吐槽不如SQL SERVER 与 国产数据库搞兼容性

PostgreSQL 现世报，客户吐槽不如SQL SERVER 与国产数据库搞兼容性