这开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内，可以解决你的问题。加群请微信联系 liuaustin3 ，（共2100人左右 1 + 2 + 3 + 4 +5）新入群的将默认分配达到5群）,另欢迎 OpenGauss 的技术人员加入。
PostgreSQL 和 MySQL 那个更好一直是DBA 们的热门话题，作为一个数据库列表中既有大量 POSTGRESQL 和 MYSQL单位的DBA Architect，我并不觉得一个单位中，PG 和 MYSQL 只能选择其一，我们的 “大象” 和 “海豚” 一直在和平共处，在不同的业务中担当他们自己具有优势的一部分。
首先说PostgreSQL ,PG数据库主打的人设是，能装，能写存储过程，能进行复杂的SQL的运算，能进行很多商业数据库中的一些功能，如在线添加索引等等。一个PG数据库里面，最近check了一下，最大的一个库已经接近10T了。
MySQL在公司主打的是，线上业务，要求的是短平快，分库分表都在数据库上应用，同时基于MYSQL的简单的特性，让大多数的业务都在业务代码中实现任务，数据库更作为是一个数据的容器被使用。
所以PG和MYSQL 在量和“量” 上在公司里面算打一个平手，数据量上PG是老大，数据库的数量上MYSQL是老大。各自在自己的业务模块承担自己的工作。所以我们并不存在 PG 和 MYSQL 二者水深火热的尴尬。
有的时候这二者还出现在一个项目里面，一起工作。但和平宁静的时间和状态，被云原生的数据库打破了，首先倒霉的就是MySQL,基于MySQL被吐槽的问题，如不能承载大量数据库，在单表，数据访问中的语句撰写要进行拆分，业务逻辑要重新梳理，程序中产生的事务的大小要进行控制，以及一些索引不能再业务时间添加，诸多的问题，主要的还是主从复制中的一些延迟，让读库的存在的意义不大，项目在设计读取从库的数据的时效性上的定义存在问题，导致业务开发中因为MYSQL的延迟造成了代码的复杂性。
基于日积月累的问题，以及在云上的特点，MySQL被逐步的淘汰也是必然，缺点多，对开发人员的不友善，在实现业务逻辑的时候，还要考虑因为用了MYSQL导致的 因为数据库问题而增加的，软件设计中的工作量，这些都是开发人员不喜欢的，同时基于一些项目就要进行OLAP轻量级的工作，就更越发的让MySQL在项目中，捉襟见肘。
经常有项目中的一些抱怨，并问是否可以用PG来替代MYSQL，我个人的看法，如果你已经在传统数据库上是一锅粥了，虽然换了PG可以解决你当前的问题，但也会让你的项目产生其他的问题。诸如高频短SQL的访问PG，让PG的idel的链接增多，尤其不进行有效的链接清理的程序，是MYSQL换PG的灾区动辄3000-5000的连接数。另更换数据库也是要成本的，大多数情况下架构师也不大有能力在MySQL玩不转后，转向PG，更怕自己玩不转。
云原生数据库的出现，让快速替换MySQL成为一个可能，没有MYSQL的毛病，但长得和 MYSQL一模一样。以我们公司为例，成百套的MySQL 在经过调研和多重的压测后，选择了PolarDB for MySQL作为替换MySQL的数据库选型。
基于MYSQL 8 到 POLARDB FOR MYSQL 8.01 8.02 的平替的特性，让更换掉MySQL 和 MYSQL TO MYSQL 一样的简单，没有什么挣扎。可替换后的一些功能的变化，让使用过POLARDB 的开发者在一段时间后，尤其架构师，彻底的把 MYSQL 打入冷宫，从前年的一个大项目全部更换了POLARDB 开始到稳定运行了快两年的时间，让其他的项目中的开发人缘，蠢蠢欲动，今年2024年开端就继续是 MYSQL TO POLARDB ，搞的不少项目都在排队准备换数据库。
在这些开发的眼里更换了POLARDB 就如同有了一个救世主，在开发中有一些无可奈何问题时的兜底的方案，比如
开发中要求的开发速度快，就把OLAP的一些 light 加到了 polardb中，以前如果是MYSQL 那么必定过不了审，就算是过了，被中心的领导DISS 开发的不规范，被点名是常事---丢脸。
在有了 POLARDB 的一些特殊功能后，原来一些被鄙视的行为，找到了在POLARDB 正常运行的借口，因为本身就是支持 OLTP + OLAP（ light）的解决方案，所以不会有人在diss 那些尴尬的 OLAP的语句出现在"MYSQL"中，扩展的随意性，收缩的便捷性，同时买一个POLARDB =2 个 MYSQL W+R 让领导也有占了大便宜的感觉，所以最终在 MYSQL TO POLARDB的工作中，基本没有反对的声音，从非数据库角度的 财务账簿好看的基础上，非数据库因素的反对的声音也没有。
当然一点反对的声音没有那时不可能的，如被绑定到X云，POALRDB 好用，把开发都惯坏了，以后不能进行读写分离的设计了，Polardb就自主解决了。遇到这些问题，实际上也没有什么好的解决方案，或许先活下去的，先着重眼前让我也顾不上，“长远”的眼光，俗话说先过了鬼门关，你在说喝不喝孟婆汤。
在工作的不到3年的时间里面，已经眼见MYSQL 从公司的大红人，变成了小蓝人，新项目选择的MYSQL的越来越少，老项目替换MYSQL的越来越多，谁不希望自己的系统更稳定，遇到问题有更多的数据库解决方案，而不是告诉你 因为你用了MYSQL 所以你要 XXXXXXX 的规范和要求。甚至现在我有一些希望MYSQL 还能继续保留的怨念，好像我们把一直勤勤恳恳的MYSQL 抛弃了。
最终有了云原生，让一直和MYSQL 和睦相处的 PG 换了新邻居，MYSQL 在公司内已经逐步完成了自己的历史使命，别了司徒雷登.MYSQL ，怀念你 MYSQL！
基于可能的有人认为这是一个充值贴，或广告贴，你对Polardb 有什么研究，呵呵，我呢也算了算，截止到去年8月份，PolarDB的文章在公众号就有 40篇了，到现在50篇也得有了，如果是充值，PolarDB 的想想给我的送多大礼 ！
最下面附带去年两场直播中的一场直播的 PPT，里面有POLARBD的问答
https://mp.weixin.qq.com/s?__biz=Mzg4NDA0NTEwNA==&mid=2247498682&idx=1&sn=df9a699e9d78c34627afda9bd646c967&chksm=cfbc9fe5f8cb16f325c09e00b956631e0cee3aa36f61dd38018c4a7e6bb03b52ad46529a0241&token=1780564896&lang=zh_CN#rd
https://mp.weixin.qq.com/s?__biz=Mzg4NDA0NTEwNA==&mid=2247499273&idx=1&sn=57e867a6f0a89ba77826b971e55598da&chksm=cfbc9a56f8cb13405e0edfb15764b3c80729c9c86260a4c181f57b3f92eb252abf9a9066be7f&token=1780564896&lang=zh_CN#rd
