題記：

先吐槽~~，這周末給屌絲哥（@應元）給廢了。

有這么一個需求，希望通過binlog去恢復數據庫某個時間段內數據的變化情況。

正文：

先說一下為什么用binlog可以做這么一件事情。

由于我們的binlog采用ROW模式，那么binlog會記錄每一條數據所有列的變化信息，這些信息，我們就可以認為是一個數據源。

首先，我們先看一下binlog，通過命令行

mysqlbinlog –no-defaults -v –start-datetime=”2012-10-01 00:00:00″  –stop-datetime=”2012-10-1 02:00:00″ mysql-bin.000001 > tmp.log

去解析binlog。INSERT、UPDATE、DELETE三種操作如下圖：

圖中的@1、@2就是表示表a的列名，等號后面的信息就是該列的值。

我們打算通過拼裝這些信息，將所有的操作都轉換成INSERT操作，重新插入到數據庫中，這樣就可以看到一個數據的變化軌跡。

當然，我們需要注意一點，將表結構中的主鍵替換成普通索引，將唯一約束去除，保證每一條拼裝出來的sql都能順利被執行。

對于INSERT和DELETE兩個操作，其數據項是唯一的，而UPDATE則有兩部分。由于是順序操作，所以我們需要的是UPDATE中SET之后的部分，即變化后的數據。

我們看一下列子：

首先我們有一個表a，結構如下：

然后我們對其做了一些操作，如下：

假設這些操作的時間在2012-11-25 16:20:00 至 2012-11-25 16:21:00內操作。在之后的時間內也被操作過。

現在我們就想看到在2012-11-25 16:20:00 至 2012-11-25 16:21:00內的操作內容。

通過該思路的方法，恢復后的數據庫內容如下：

這樣我們就可以觀察到表a中id=1的num列的變化過程。

經典場景：商品減庫存。

最后，方法還有不足之處：

如上圖中紅色方框內這兩條數據，其實應該表示一個是UPDATE之后的結果，一個是DELETE的結果。我們在考慮時候對表結構進行變更，增加新的一列，表示是什么操作引起數據變化，這樣就更加直觀的看到數據變化的軌跡了。

PS：下篇文章我們會給出在實現過程中碰到的問題以及實現工具。