這是學習筆記的第 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,日誌切換切換很頻繁，數據量的增長相對較快，所以這很可能是一個密集型寫入的日誌業務。
通過這些數據分析，就會得到一些有效的數據模型。