这是学习笔记的第 1809篇文章
一直以来对于MySQL的binlog日志的统计和分析是工作中的重点内容，因为通过日志量这样一个维度能够反映出数据库的变化情况，但是显然MySQL官方没有好的工具来做这个分析。
有的同学说有show binary logs这个命令，仔细想想，这个命令的输入只有binlog的下标和偏移量大小，但是没有时间标识，如果我要查看一段时间内的日志变化情况，需要借助其他的技术手段才能够补充实现。
以这个为出发点，我觉得很多DBA对于自己负责的数据库业务其实是不了解的，比如这个数据库数据量情况，数据变化情况，对象（表，索引）的分布情况，整体的SQL质量情况等，或者更高的一个要求，我们负责了100套数据库业务，这些数据库半天内产生了多少数据量，什么时候会是业务的高峰，什么时候相对会比较平稳，这些是我们应该了解的，但是显然这是我们忽视的。
如何让有些工作看起来更加具有落地性，一种方式就是把你推到一个高度之后，你再来看看原来的目标，会有一些思路，所以在纠结做还是不做的时候，至于以后怎么样，怎么分析和利用，其实是另外一个层面的事情。
比如我们设计了一个初步的数据模型，会分时间周期来对所负责的数据库做一层数据抽取，抽取的信息其实也是在不断的完善中逐步敲定的。
我取出一部分数据来做一个简单分析，就会发现其实很多业务我们换一个角度去分析，会有很多额外的收获。
比如下面这个数据库的情况，可以看到binlog的保留天数是1天，日志在2天内切换了30多次，按照binlog的配置为1G,binlog是增长了30G左右，而整体的data目录下的数据增长了600M左右。所以通过这些数据可以得出一个初步的结论，这个数据库是一个典型的TP业务，数据变更很频繁，算是一个偏TP层面的业务。
再来看一个数据，这个数据库的数据量不大，从两次的时间采集的数据来看，日志没有切换，更关键的，偏移量没有发生任何变化，所以通过这个层面来看，这很可能是一个僵尸业务，可以持续关注。
再来看一个业务，这个数据库的数据量比较大，有60多G,日志切换切换很频繁，数据量的增长相对较快，所以这很可能是一个密集型写入的日志业务。
通过这些数据分析，就会得到一些有效的数据模型。
