其实在技术领域，不同的看法是很正常的，最近两个文字的集合，让我看了以后不是很.......,具体是那篇我觉得不重要，重要的是观点哪里不同
先说第一个，文字中提出 NEW SQL 这样的数据库不稳定，并且都处于配角的角度，而分库分表都是业务的核心，所以不用NEW SQL 要分库分表
View:
1 如果是业务核心，数据量较大的情况下，那是什么样的业务核心可以来分库分表，而分库分表的弱点在哪里，文中我没有找到
2 通过文字集合中，可以看到业务的逻辑属于简单的，并不是复杂的情况，也不会出现比较复杂的事务回滚。
3 由于分库分表的某些原因，最终部分查询要通过ES 来进行
通过以上三点，其实不难得出一些问题的汇总
1 这样的分库分表，出现在互联网企业，在金融行业并没有丰富的经验，或使用的案例
2 业务比较简单，如果类似像金融业务中，一会客户要变更贷款期限，一会要大额还款，这样的复杂的场景，估计分库分表解决起来是很困难的。
3 使用分库分表的企业，基本上都有强大的技术支持和解决问题的强大技术积累和相关人员。
问题：
1 如果是金融行业，对事务要求严格的业务场景，并且业务复杂，需要强一致回滚的情形下，分库分表的弊端马上就显现无疑。
2 维护麻烦，站在开发者的角度上看，分库分表必然是可行的，但对运维人员，分库分表对运维的压力可想而知，稍有差错就会出现很大的问题。各种对硬件和数据库等方面的高可用就要做的踏踏实实，这就需要另一个话题，成本本来可能几台机器就完成的事情，非要牵扯进来几十台，上百台的机器，我觉得开发人员是站着说话，不看运维的腰。
3 后期出现问题不好进行处理，如果是简单的分库分表还好，如果是复杂的分库分表，在数据出现差错，或出现故障后的恢复都不是一件令人愉悦的事情。
综上所述，分库分表是互联网的标配，但传统企业是没有力量给你做这样的事情的，所以传统型企业，或二线互联网企业都需要更简单的，一体化的解决问题的方法。
例如，NEWSQL，这样的数据库（TIDB）的出现就是解决这样复杂的问题，并且在维护成本，资源消耗上，都有分库分表不能匹及的优势。新生事物当然需要时间，而且现在也有部分单位将NEWSQL使用到核心的系统中，不用--你永远都在边缘，用了采坑了，你才能体会新型数据库给业务，开发，运维以及公司带来相关的好处，例如节省开发人员，运维人员的成本，加快业务的上线，以及稳定性等等的好处。
另一篇文字是直接拿 MYSQL 8 和PG 10来对比，为什么不用MYSQL 5.X 和PG 10来比，MYSQL现在最新的版本是 8 ，但PG 最新的版本是 11 , 而PG 12 也在Bate，首先这样的对比我就觉得不大负责。首先对比要站在公平的角度，而不是拉偏手。例如下面的图，
明显就是利用某些数据库的优势，来对比，我想问一句，怎么不提流式复制
又如同 MYSQL的 double write , PG 用full page 来解决数据在crash下的场景，这样关键性的不一致，到底哪个更好，文章中也没提及。
在简单的说完一些参数后，就得出两个数据库特性一样？我真不知道从哪里看这两个数据库特性一样了。
1 MYSQL 是 B tree 索引，其他的索引类型没有（请不要说HASH）
2 PostgreSQL 支持的索引类型，Btree GIN GIST 等索引和直接进行模糊查询(like %字符%）走索引的方式，ORACLE 都能被气得上房吧
3 从单表的容量上来说POSTGRESQL 是可以支持到 32T 的容量（当然没有人这样搞）但POSTGRESQL 的堆表存储的方式，对大数量的支持不是开玩笑的，大数据greenplum 的内核是谁？，两种数据库在数据存储上不是一个量级的，要不你何时听说postgresql 要分库分表。
4 内存的使用和分配方式，也不同，一个是尽量划更多的内存给INNODB BUFFER POOL SIZE ,一个是尽量考虑多留内存给系统，这在内存使用的原理上也是不一致的。
5 对数据查询处理的不同，POSTGRESQL 有 HASH JOIN ,BITMAP，NESTED LOOP 等多种数据查询和处理的方式，MYSQL, 是 NESTED LOOP，NESTED LOOP ，NESTED LOOP 这的说三遍，因为只能说这个。所以在数据的查询速度上尤其大数据量上来说，那个更好一目了然。如果不信你直接去 COUNT(*) 一下 千万级的表，你可以马上得到答案。
应该用每个数据库的优势去打擂台，我一定不会把POSTGRESQL 推到分布式数据库应用的领域，同时我也不会把MYSQL 推到单表上T 的应用。
另外说到 POSTGRESQL 对 index-only scan支持不是很好还的看版本
6 文字中，还未提及MYSQL 在表设计中的不同于POSTGRESQL 设计表的不同之处，MYSQL 的是B TREE 的方式，所以主键的自增应该是设计的一个指标，而POSTGRESQL 则正因为是堆表，所以在主键的设计中并不考虑这一点，而恰恰这对于业务很重要，如果你非要给你的主键设置为UUID ，则我认为 POSTGRESQL 是很合适的，而不是MSYQL.
7 众所周知在MYSQL的设计中很少有存储过程的存在，而POSTGRESQL 是可以很好的支持函数和存储过程，这是在两个数据库使用中的根本不同之一。你很难去想象往MYSQL 中塞入大量的存储过程，并对他进行调用，同时你也很难再使用POSTGRESQL 时不去使用存储过程或者函数，因为他的性能不低。
所以和那篇文字的不同，我还是会在OLTP 及分布式，灵活复制中选择 MYSQL ，但我一样会坚持在传统领域,复杂关系，存储过程函数等需求中寻求POSTGRESQL 给我的安全感 ，没有最好只有更适合。
最后通过这两篇文字个人浅薄的看法，积极接受新事物，数据库没有亲生和继子之分，工具掌握的越多越好。
