MYSQL 的 程序设计中的 “坑” 一例

最近ORACLE 12C 的某个BUG 霸占了微信公众号，仔细看了看，其实也还好。每种数据库在上了新版本后都会有问题，其实不光是数据库，每个软件都包含着BUG，而发现了BUG 后如何处理，倒是变得重要。

以MYSQL 举例,使用的是 percona 5.7.23 的 MGR 一个测试库，磁盘的环境不是太理想，这是我们早先就知道的，I/O 缓慢。然后就有了这样一个设计，因为要进行客户的信息处理，将信息发送给银行，而在验证用户的过程中，原先的设计是批量的验证插入，发现有一个客户的信息有问题，就直接对这一批次的信息进行打回， 而后期由于业务需求，说要一个个的来，这样不会耽误这个包中符合的客户信息被打回。（业务上考虑是有道理的）

然后就在程序修改后，MYSQL 的MGR 的集群中的服务器开始出现下面的NOTE，很明显，复制出现了点问题。

上图中的的NOTE 虽然不是ERROR ，但显然是 waited at clock conflicts 的数值不断的升高， 以及 when workers occupied 后面的数字（毫秒）。

经过和程序员的沟通后，发现原先是批量的插入，现在是单条的插入。而数据库ERS 都知道，任何数据库的插入都倾向于 批量的插入和提交，（请不要误会批量的含义，这里的批量是指批量类似存储过程似的综合性的事务，例如像ORACLE 更新几十万条语句就写一个 UPATE 语句这样的糟糕设计）。这和数据库的本身的原理有关，批量的插入产生的I/O消耗，和 单条快速的循环插入对于数据库的I/O系统的压力是不一样的，并且不光是插入而且在插入的时候还要对插入表的唯一索引进行一个CHECK，所以带唯一索引的表，在高速插入的时候的性能消耗会更大。（其实一个程序的设计要考虑的事情很多，有时想的很简单，但业务，系统本身的限制，给程序的开发者们提出了更高的要求，同时一个数量级的不同，也直接回影响系统的整体设计）

其实这里还应该想到一种应用级别的监控与系统性能监控的综合体，很多时候系统性能不佳，往往伴随着，刚刚更改系统的代码，新功能的添加，等等，如何搭建一个能反应系统详细问题的监控系统就变得很重要了。

最后的结果，程序人员去尝试修改不大符合数据库使用的原理的程序，然后再看。