Polardb for mysql 如何更好的开发与使用经验总结（1）

最近一段时间，在快速熟悉POLARDB FOR MYSQL 的产品，并且也在大量的应用此产品。实际上一款数据库产品在使用中经常会对比其他的数据库产品，例如  POLARDB FOR MYSQL  对比 MYSQL RDS 在使用和开发中有什么需要注意的，或者二者不同的，就是一个如何更好使用POLARDB 的着手点。下面就从目前的使用中的情况，来分析如何更好的使用这款数据库产品。

首先POLARDB 是一款带有智能中间件的数据库产品，这点对于POLARDB 是十分重要的

1  基于POALRDB 的结构，与智能读写分离的特性，和透明扩展的特性，一款智能的中间件，架设在数据库上是必须的，也是解决方案中亮点。

2    在使用中需要注意调整好中间件产品的配置，不同的配置应对不同的数据库性能和对业务逻辑的相应。

这里总结了数据库POLARDB 的数据库代理的部分特性,见下图

实际上POLARDB 的部分先进性，如果脱离了代理，部分功能是无法完成的，这点和MYSQL 不一样，需要注意，数据库代理和POLARDB 是一体的，不可分割个。

所以针对POLARDB 的监控中，不光应该监控数据库，同时也应该监控数据库代理的情况。

除此以外就是POALRDB 的另一个卖点，并行化，实际POLARDB 的并行化比官方版本的并行化提出的要早，同时并行化的限制和原理设计也与MYSQL 官版的原理不同。

下面总结一些关于并行方面的使用中的注意事项 

1  在CPU核心数较低的POLARDB 数据库中，并行启用的概率较低，如果数据库中设计了大表，并且其中有一些 count(*) ，或聚合的操作，建议可以将CPU 核心数提高，增加可以进行并行的可能性。

2 在使用并行特性的情况下，数据库的隔离级别建议为READ-COMMIT 而进来不要使用 repeatable read 的模式，READ-COMMIT 可以扩大可以使用并行的处理语句的范围，如 insert select  等这样的语句

3  对于数据表中，建立索引，尽量建立复合型索引，如果使用INDEX MERGE的情况下，是无法进行并行处理的

4  并行下执行语句的情况下，不在语句中使用ORDER BY 的情况下使用LIMIT 查询每次的结果可能不一致，同时在使用  select * from share的情况下，行锁的消耗比不使用并行的要多。

除此以外，我们在针对POLARDB 的使用中，根据POALRDB 本身的特性（请参见之前POALRDB 的原理文字的翻译）

总结出初步使用POLARDB 应该注意的地方

1  如果系统是单纯的主键访问的设计，同时可以使用MYSQL 8.0 的版本的数据库引擎，此时使用 MYSQL OR POLARDB 性能上都基本可以满足日常使用。Polardb  针对数据表更大的情况，对比MYSQL 有相关的优势，尤其采用并行的情况下。

2  POLARDB 针对CPU的核心数有更多需求，实际上针对MYSQL8.0后的版本也针对各种后台线程有优化，所以MYSQL 使用多核心对数据库无意义的思维，可以换换了，CPU 更多，针对POLARDB 更有利，当然针对MYSQL 也有利。

3  针对POLARDB 基于REDO LOG 进行数据复制和传递到从库的方式，REDO 是POLARDB 的瓶颈点，所以针对POLARDB 主库 和 从库的性能不能使用的太苛刻，尤其针对更多的UPDATE 的情况，建议使用分库的方式将写性能分散到多个数据库节点，而不是单独提高POLARDB 的CPU 和内存 来解决问题。最后如果是高频的UPDATE 操作的应用设计或业务逻辑，会导致堆积REDO LOG ，从库无法快速消费，导致性能上出现问题。反过来由于从库未应用REDO LOG ，导致查询数据也无法分散到从库上，导致主库的性能进一步被消耗。 

4  对于事务本身来说，不建议大事务在POLARDB 上频繁的运行，原理也是无论是在读库上运行还是在写库运行大事务，会导致上边提到的问题，并且POALRDB 本身采用的数据页面的刷新，也是希望频繁写，而不是写大块的方式，所以事务进来不要太大。

5  针对在只读库上运行OLAP 的事务也是不建议的，主要的考虑还是如果在从库运行大量的OLAP 会影响 REDO LOG 在从库的重放，会导致更多的REDO LOG 堆积在主库，导致主库和从库的性能下降。

6   关闭POLARDB 或重启POLARDB 时建议避开数据库正在运行大事务的情况下，此时关闭数据库或重启数据库，数据库的重启的时间需要对比不运行大事务的情况下，需要更多的时间。

7   注意进行DDL 操作的密集度，与操作的时间，操作DDL ，POLARDB 因为要保证从库的MVCC 与主库的数据库 MVCC 的结果是一直的，会采用锁的方式，禁止在DDL 时主从数据不同导致在从库读取到错误的版本。如果DDL 时间过长触发POLARDB 设定的容忍时间，DDL 操作会直接失败。

随着更多使用POLARDB的数据库产品，会逐渐更加熟悉POLARDB 的产品特性和适合使用的方式，后续还会不断的学习和总结相关的经验。