匪夷所思的数据库延迟-

    上周分析了一个数据库的主从延迟。起因是一个数据库做了一次迁移。迁移前配置为24C96G的物理机，迁移后为4C16G的虚拟机。迁移后发现主从有延迟。从硬件环境来说确实下降了许多。所以第一感觉就是硬件环境不足。

    不过接下来的反馈有点莫名其妙。数据库是MySQL主从架构，既然是主从，那么就是要开启Binlog。根据处理此事的人员说，从库开启binlog就延迟，关闭就正常。（这点很难理解）于是我建议他们还是开起来，看看延迟在什么地方。

    随着Binlog开启发现，在show slave status中看到了延迟。但是数据还在写入只是延迟越来越大。通过对主库和从库的写入分析，主库每秒写入100多条，从库每秒写入20-30条。所以延迟越来越大。按理说数据库每秒写入100多的速率实在是不高。

    而且主库写入本身就延迟，更加不要说从库的传输。主库看到都是类似这样的：

    通过iostat查看主库每秒写入是从库的很多倍，而且这个写入量比起一般的业务系统也高。所以我给他的定论是： 从数据分析来看最终定位是业务场景和硬件吞吐不匹配。出现这类情况说明写入有一定瓶颈。

   因为在几年前我就处理过这个数据库的问题，当时就是觉得有多个问题：

  1.数据库选型问题。该场景称之为分析，但凡有点数据库概念的朋友都知道。社区版MySQL不太适合大量数据的分析（使用索引的少量数据报表分析是可以）。MySQL的OLAP是需要heatwave支持的。而这个是要求企业版而且要在云上。

之所以出现这种情况都是开发或者供应商选型，会什么选什么。当然可能觉得会实际上未必会。

   2.数据全量同步，几分钟同步一次导致99.99%的数据在重复擦写。

   这些问题一直残留着，所以结合以前的病历，我觉得是选型到业务场景到实现方式的问题。就这样上报了。过了几天有人反馈给我说，在这两个上面发现两个参数：

binlog_group_commit_sync_delay=25000
binlog_group_commit_sync_no_delay_count=20

把这两个参数去掉就都正常了。而这两个参数是迁移时候照搬过来的。

说实在的我根本没想到这个问题是参数影响的，这两个参数一看名字就知道了，就是binlog同步延迟。但是从来没用过。不知道最初是什么样的脑回路去设置这个。纵然从事多年数据库的人也没有去设置过这个。就整体参数而言这两个绝对属于小众非主流参数。

1. binlog_group_commit_sync_delay，等待多少微秒后才进行fsync；

2. binlog_group_commit_sync_no_delay_count，达到等待的事务数量后调用fsync操作,如果binlog_group_commit_sync_delay为0，此参数不生效；

   以上控制组提交的参数需要结合业务情况进行配置，当多线程(并发量)写时，效果更好。这是这两个参数的介绍。其实读到这里还是忍不住要吐槽。

出现这种想法和设置，还是开发不懂数据库还要乱来。因为正常的一个数据库每秒写入1000-2000都不是问题。其实是大量无用功导致的数据大量的擦写，不去思考怎么巧妙处理数据（能不能不要重复取数据？），倒是看数据库改什么能加快些。以至于事务隔离级别用的是未提交读。

不过这两个非主流参数，希望所有人不会再用到他们。  

企业中最大的成本就是没有好好使用数据库！