开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群（共700人左右 1 + 2）。

数据库最近几年的选择越来越多，数据库之间的互卷的案例也是此起彼伏的发生，而基于MYSQL 核心的 MYSQL RDS 产品，正在接受猛烈的冲击，线下的MYSQL 可能看上去还是有比较稳固的地位,(看上去)。 但基于云上的MYSQL 的RDS 产品正在被替换和被其他的数据库产品 DISS。

今天我们就现身说法，谈谈我们使用阿里云数据库产品的在 MYSQL RDS 和 POLARDB FOR MYSQL的一些感受。当然感受很多都是感性的，我们尽量不让这篇文字成为一片感性的文字。

1   遇到紧急问题，救火的速度

这点实际上是很多数据库使用者最关心的部分，数据库在一些小企业没人管，出了问题没法管，不会管的情况比比皆是，大多的开发者都是使用数据库 增删改查， 而涉及到数据库内部的使用原理和问题发生后的解决都是“肌无力”。

那么在这样的情况下，如何快速的解决问题，是一个需要使用者关心的问题，谁的数据库可以快速扩展，将数据的压力分散，或者添加资源后，马上立竿见影的解决性能问题，是一个需要关注的问题。

在这样的情况下 MYSQL RDS 产品基本上是不能有所建树的

1 扩展能力弱，扩展速度慢，扩展后对于应用生效的速度慢或根本无法生效

举例，你的应用因为查询的问题导致的数据库，主从节点的压力上升，导致的性能问题，你是无法通过单一的添加MYSQL 的从节点来解决问题的，因为应用无法判断你的数据的主从一致性和数据的准确性，完全将操作打散到不同的从库。所以添加从节点对于MYSQL RDS 的可行性不能说 为0 ，只能说，基本没有用。

相对于POLARDB FOR MYSQL ，那么这个问题基本上15分钟内就可以解决（我是可以用脑袋来保证的，因为我们试过多次，压测多次），扩展节点后，相关的压力会快速的打入到新的从库，分担从库的读压力，并且如果你事务控制的好，打散的好，那么POLARDB FOR MYSQL 本身的读写分离自主控制，让你的读事务会分散到不同的从库中，读的压力会很快被救驾，业务持续的可能能行会更好。

那么在这样的场景下，节点的快速伸缩，看似没有什么，但如果你在危难的时候，你就知道这有多么的重要。

2  真并行，让硬件的使用率提高

使用MYSQL的同学一直都在MYSQL和 硬件之间的匹配度上动脑筋，MYSQL 5.X 的“一根筋”，延续到了 MYSQL 8 的 前部分版本，即使后部分版本添加了并行，但你可以使用这些并行是否能让你的大部分SQL 满足并行需求，回答是NO。

而POALRDB 的并行方式是自有的代码和逻辑，对于聚合操作以及常用的操作，只要你的硬件的CPU 核心数大于 4 CPU ，那么并行就可以在大部分语句中有被使用的可能，最大化的利用多核心CPU的处理能力， 以及POALRDB 的 IOPS 高性能的利用。

3    IMCI  不是HTAP ，但是我们需要这个功能

现在的数据库动不动就是 HTAP ，POSTGRESQL 的非开源版本都已经添加了列式的概念（商业），而现在没有列式处理的方式，已经成为一个数据库的短板，我们不需要OLAP ，我们就在一些数据库中进行 COUNT ,AVG ,SUM ,GOURP BY  等操作， MYSQL 的短板就产生了，而这些是无法在一些项目汇中避免的，我们怎么能解决这个问题，如果光靠开发，那么MYSQL 难道真的就是一个  数据容器。 

POALRDB FOR MYSQL ，我们目前一直在研究和压测 POLARDB 的列式节点IMCI ，我们并没有贪心到，要MYSQL 处理分析性的工作，但是对于那些MYSQL 的弱点的问题，POALRDB 是有解决方案，并且在我们初步的使用中，给了我们一个希望，就是IMCI 有限度的使用，让我们天天头疼的问题，可以有头疼片可以吃，可以有解决方案， 不是和开发讲 MYSQL  这个不行 ，那个不行 ，还是不行，你要改这个，你要改那个。

我们会强有力的告诉开发，这个问题如果你们暂时无法解决，或解决的成本很高，我们可以通过IMCI 的方式来暂时化解，给开发和架构一个修改程序前的缓冲，而不是逼死他们。

4   更高的数据存储能力更安全的数据存储能力

说到这里MYSQL本身是可以进行数据的压缩的，但是这并不够，MYSQL 的数据压缩可以说是开源数据库里面，一个不可以  可圈可点的存在，在云上数据存储是要花费大量金钱的，而数据的安全性对于一些乙方 也是非常重要的，MYSQL的灾备是在主从，切换这样的高可用和数据安全能力，但不得不诚然，这样的方式，会有一个特点  

要不性能差，要不安全差， 这就是MYSQL给我们留下的一个谜题，半同步是MYSQL 的数据安全的杀手锏，但性能的影响会产生，同时他也只是一个半同步，当然 INNODB  CLUSTER 可以调整成强一致，可性能的 “绯闻” 又出来了，当然在云上的MYSQL 也不要想什么 INNODB CLUSTER ，没有。

基于硬件 1写三的方式，让数据从硬件的模式就是安全的，你不用考虑什么数据延迟，没有延迟。数据存储会自动压缩，比MYSQL 有可能多40%的空间。

5  培养更舒服的开发者

说实话 MYSQL 这个数据库是一个磨炼开发者，让开发成本和架构变得复杂的数据库，因为你要考虑的问题太多，稍有不慎，那么后期修改的成本会很高，比如我读写分离怎么做，MYSQL 我怎么判断写库读库的延迟，写库上有的数据，读库上没有我怎么办，等等，等等

POALRDB FOR MYSQL 有一个强有力的伙伴,POLARDB的代理，匹配POLARDB 的底层原理，通过REDO进行数据复制中的事务号来判断从库与主库的数据差距，以及只读事务在从库的可行性，不用关心从库有没有数据，会导向主库，若从库和主库一致，代理会导向读从节点去完成事务，有多个读节点时通过当时的连接数来打散对数据库节点的访问，结果为让开发者更注重业务 而不是在架构。

6   可以匹配不同的数据库存储引擎

一些POALRDB 特有的语句和功能，这里就不多解释，这些属于锦上添花的功能。POLARDB可以挂载 X-Engine 引擎让POLARDB 变成归归档库，通过高压缩比的X-ENGINE ，大部分语句都支持在压缩引擎上执行，如简单的数据查询工作，则样可以将冷热数据进行分离，通过DTS 将冷数据过度到 POLARDB + X-engine 的数据节点中，完成动态的冷热数据分离。

在一年多的POLARDB 的使用中，我们持续发现POLARDB 中的新功能和新特性，运用到实际的生产中，大大的提高了生产力，在开发者使用POLARDB 和 MYSQL 基本无差异的情况下，完成了数据库产品的切换，后续我们还会发现更多的使用的方法，解决更多的实际问题。

总结：DBA 手里的最大的武器就是数据库，数据库本身的能力是DBA的底气，所以DBA 在数据库选型和对于不同数据库的了解是一个基本的能力。