解析MYSQL BINLOG 二進位制格式(6)--UPDATE_ROW_EVENT/DELETE_ROW_EVENT
原創：轉載請說明出處謝謝！
上接
http://blog.itpub.net/7728585/viewspace-2133188/ 解析MYSQL BINLOG 二進位制格式(1)--準備工作
http://blog.itpub.net/7728585/viewspace-2133189/ 解析MYSQL BINLOG 二進位制格式(2)--FORMAT_DESCRIPTION_EVENT
http://blog.itpub.net/7728585/viewspace-2133321/ 解析MYSQL BINLOG 二進位制格式(3)--QUERY_EVENT
http://blog.itpub.net/7728585/viewspace-2133429/ 解析MYSQL BINLOG 二進位制格式(4)--TABLE_MAP_EVENT
http://blog.itpub.net/7728585/viewspace-2133463/ 解析MYSQL BINLOG 二進位制格式(5)--WRITE_ROW_EVENT
class:Update_rows_log_event
event:UPDATE_ROW_EVENT
event_code:31
class:Delele_rows_log_event
event:DELETE_ROW_EVENT
event_code:32
自從5.1.18開始,row模式下的update/delete的event
這部分將UPDATE_ROW_EVENT和DELETE_ROWS_EVENT放到一起因為了有了前面WRITE_ROW_EVENT 的
基礎這兩個基本和他一致，只是要注意UPDATE_ROW_EVENT存放了前後印象
--fixed data 10位元組(5.6,5.7中描述為 ROWS_HEADER_LEN_V2)
6 bytes 表ID
2 bytes 保留
2 bytes 文件中並沒有描述
原始碼中描述為：
uchar *m_extra_row_data; /* Pointer to extra row data if any */
/* If non null, first byte is length */
具體參考前面一篇(解析MYSQL BINLOG 二進位制格式(5)--WRITE_ROW_EVENT)
--variable data part
packed integer：表中欄位個數，這個地方為packed integer自行參考原始碼
uchar *net_store_length或者參考第一章
(解析MYSQL BINLOG 二進位制格式(1)--準備工作 )
var-size:文件解釋為每一位代表是否欄位用到了 長度為INT((n+7)/8) n代表欄位數量
原始碼描述為 m_cols; /* Bitmap denoting columns available */
測試表現這一位元組和binlog_row_image設定有關，預設為FULL每一個位元組始終為
0XFF
var-size-update:UPDATE_ROW_EVENT專用和前面描述的一致，但是表示的是後印象，也就是update後的資料
var-size:每一位代表的欄位的值是否為NULL，長度為INT((n+7)/8) n代表欄位數量，
他採用一個點陣圖的方式。
1：NULL
0：NOT NULL
var-size:這部分就是真正的資料了。
var-size-update:
var-size-update:
這兩部分為UPDATE_ROW_EVENT專用和前面描述的兩部分一致，但是表示的是後印象，也就是update後的資料
接下來進行實際的解析：
執行語句
mysql> select * from testnull2;
+------+-------+-------+
| id | name1 | name2 |
+------+-------+-------+
| NULL | test | NULL |
+------+-------+-------+
1 row in set (0.01 sec)
mysql> update testnull2 set id=2,name2='test',name1=NULL where name1='test';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> delete from testnull2;
Query OK, 1 row affected (0.02 sec)
使用./infobin (自己開發 我放到了雲盤)
[root@testmy data]# ./infobin test.000184
Check is Little_endian
Author: gaopeng QQ:22389860 Mail: gaopp_200217@163.com
Waring: This tool only Little_endian platform!
Little_endian check ok!!!
-------------Now begin--------------
Check Mysql Version is:5.7.13-log
Check Mysql binlog format ver is:V4
------------Detail now--------------
>Gtid Event:Pos:194(0Xc2) N_pos:259(0X103) Time:1486949924 Event_size:65(bytes)
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000450
-->Query Event:Pos:259(0X103) N_Pos:331(0X14b) Time:1486949924 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN
---->Map Event:Pos331(0X14b) N_pos:389(0X185) Time:1486949924 Event_size:58(bytes)
TABLE_ID:210 DB_NAME:test TABLE_NAME:testnull2
------>Update Event:Pos:389(0X185) N_pos is:441(0X1b9) time:1486949924 event_size:52(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000450
>Xid Event:Pos:441(0X1b9) N_Pos:472(0X1d8) Time:1486949924 Event_size:31(bytes)
COMMIT 1000450 /*!add by tool*/
>Gtid Event:Pos:472(0X1d8) N_pos:537(0X219) Time:1486949930 Event_size:65(bytes)
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000451
-->Query Event:Pos:537(0X219) N_Pos:609(0X261) Time:1486949930 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN
---->Map Event:Pos609(0X261) N_pos:667(0X29b) Time:1486949930 Event_size:58(bytes)
TABLE_ID:210 DB_NAME:test TABLE_NAME:testnull2
------>Delete Event:Pos:667(0X29b) N_pos:712(0X2c8) Time:1486949930 Event_size:45(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000451
>Xid Event:Pos:712(0X2c8) N_Pos:743(0X2e7) Time:1486949930 Event_size:31(bytes)
COMMIT 1000451 /*!add by tool*/
可以看到我們的update和delete的位置
------>Update Event:Pos:389(0X185) N_pos is:441(0X1b9) time:1486949924 event_size:52(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000450
------>Delete Event:Pos:667(0X29b) N_pos:712(0X2c8) Time:1486949930 Event_size:45(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000451
現在使用mysqlbinlog --hexdump -vv 進行解析
先來看update event
二進位制解析
# at 389
#170213 9:38:44 server id 93157 end_log_pos 441 CRC32 0x21c0591d
# Position Timestamp Type Master ID Size Master Pos Flags
# 185 24 0e a1 58 1f e5 6b 01 00 34 00 00 00 b9 01 00 00 00 00
# 198 d2 00 00 00 00 00 01 00 02 00 03 ff ff fd 04 74 |...............t|
# 1a8 65 73 74 fa 02 00 00 00 04 74 65 73 74 1d 59 c0 |est......test.Y.|
# 1b8 21 |.|
# Update_rows: table id 210 flags: STMT_END_F
-vv輸出
### UPDATE `test`.`testnull2`
### WHERE
### @1=NULL /* type=3 meta=0 nullable=1 is_null=1 */
### @2='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
### @3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
### SET
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### @2=NULL /* INT meta=60 nullable=1 is_null=1 */
### @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
分解：
--event header 部分就不解析了table id 210，
--hexdump也明確的解析了，不理解參考前面的文章
# Position Timestamp Type Master ID Size Master Pos Flags
# 185 24 0e a1 58 1f e5 6b 01 00 34 00 00 00 b9 01 00 00 00 00
--fixed data
d2 00 00 00 00 00：表ID就是./infobin中的TABLE_ID:210 也是mysqlbinlog中的Update_rows: table id 210
小端顯示
01 00：保留
02 00：m_extra_row_data,這部分是我看原始碼找到的。
--variable data part
03：表中欄位個數，當然我建表就是3個欄位
ff: 原始碼描述為 m_cols; /* Bitmap denoting columns available */
ff：update專用和上面一致
----update前印象資料：
fd: 11111101 代表欄位@1=NULL和@3=NULL，但是欄位@2不為空這和mysqlbinlog解析的一致
@1=NULL /* type=3 meta=0 nullable=1 is_null=1 */
@2='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
@3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
04:var 長度04 就是資料'test'的長度為4，這個也就是@2='test'事update的前印象
74 65 73 74：字串'test'
----update後印象資料(update 專用)：
fa：11111010，@2=NULL，但是修改後@1和@3不為空和mysqlbinlog解析一致
@1=2 /* INT meta=0 nullable=1 is_null=0 */
@2=NULL /* INT meta=60 nullable=1 is_null=1 */
@3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
02 00 00 00 ：也就是資料2也是@1=2也就是update的後印象，小端顯示
04： var 長度04 就是資料'test'的長度為4，也就是
74 65 73 74：字串'test'也是@3='test'也就是update的後印象
1d 59 c0 21：CRC32校驗
然後來看delete event
二進位制解析
# at 667
#170213 9:38:50 server id 93157 end_log_pos 712 CRC32 0x055741c1
# Position Timestamp Type Master ID Size Master Pos Flags
# 29b 2a 0e a1 58 20 e5 6b 01 00 2d 00 00 00 c8 02 00 00 00 00
# 2ae d2 00 00 00 00 00 01 00 02 00 03 ff fa 02 00 00 |................|
# 2be 00 04 74 65 73 74 c1 41 57 05 |..test.AW.|
# Delete_rows: table id 210 flags: STMT_END_F
-vv輸出
### DELETE FROM `test`.`testnull2`
### WHERE
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### @2=NULL /* INT meta=60 nullable=1 is_null=1 */
### @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
分解：
--event header 部分就不解析了table id 210，
--hexdump也明確的解析了，不理解參考前面的文章
# Position Timestamp Type Master ID Size Master Pos Flags
# 185 24 0e a1 58 1f e5 6b 01 00 34 00 00 00 b9 01 00 00 00 00
--fixed data
d2 00 00 00 00 00：表ID就是./infobin中的TABLE_ID:210 也是mysqlbinlog中的Delete_rows: table id 210
小端顯示
01 00：保留
02 00：m_extra_row_data,這部分是我看原始碼找到的。
--variable data part
03：表中欄位個數，當然我建表就是3個欄位
ff: 原始碼描述為 m_cols; /* Bitmap denoting columns available */
fa: 11111010 代表欄位@2=NULL，但是欄位@1 @3不為空這和mysqlbinlog解析的一致
@1=2 /* INT meta=0 nullable=1 is_null=0 */
@2=NULL /* INT meta=60 nullable=1 is_null=1 */
@3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
02 00 00 00: int 4位元組資料 2及@1=2 小端顯示
04:var 長度04 就是資料'test'的長度為4，這個也就是@3='test'
74 65 73 74：字串'test'
c1 41 57 05：crc32 校驗
至此UPDATE_ROW_EVENT和DELETE_ROWS_EVENT解析完畢
後記：
1、在UPDATE_ROW_EVENT/DELETE_ROWS_EVENT/WRITE_ROWS_EVENT中存在一個欄位值是否為空的點陣圖，如前面所說
然後緊跟了欄位資料，這樣根據點陣圖就能確定出那些欄位為NULL，而實際儲存的值中並不包含NULL欄位的資料
因為它沒有資料，同樣也為了減少儲存空間的使用，這種技術在資料庫技術中大量使用，在INNODB PAGES中也
是用到了。
2、很多閃回工具都依賴了binlog中能夠記錄了需要的所有資訊，我們也看到了update還記錄前後印象的值，那麼
也為閃回提供了條件，但是binlog_row_image會影響它的記錄方式具體參考官方手冊，但是它可以節約空間。
上接
http://blog.itpub.net/7728585/viewspace-2133188/ 解析MYSQL BINLOG 二進位制格式(1)--準備工作
http://blog.itpub.net/7728585/viewspace-2133189/ 解析MYSQL BINLOG 二進位制格式(2)--FORMAT_DESCRIPTION_EVENT
http://blog.itpub.net/7728585/viewspace-2133321/ 解析MYSQL BINLOG 二進位制格式(3)--QUERY_EVENT
http://blog.itpub.net/7728585/viewspace-2133429/ 解析MYSQL BINLOG 二進位制格式(4)--TABLE_MAP_EVENT
http://blog.itpub.net/7728585/viewspace-2133463/ 解析MYSQL BINLOG 二進位制格式(5)--WRITE_ROW_EVENT
class:Update_rows_log_event
event:UPDATE_ROW_EVENT
event_code:31
class:Delele_rows_log_event
event:DELETE_ROW_EVENT
event_code:32
自從5.1.18開始,row模式下的update/delete的event
這部分將UPDATE_ROW_EVENT和DELETE_ROWS_EVENT放到一起因為了有了前面WRITE_ROW_EVENT 的
基礎這兩個基本和他一致，只是要注意UPDATE_ROW_EVENT存放了前後印象
--fixed data 10位元組(5.6,5.7中描述為 ROWS_HEADER_LEN_V2)
6 bytes 表ID
2 bytes 保留
2 bytes 文件中並沒有描述
原始碼中描述為：
uchar *m_extra_row_data; /* Pointer to extra row data if any */
/* If non null, first byte is length */
具體參考前面一篇(解析MYSQL BINLOG 二進位制格式(5)--WRITE_ROW_EVENT)
--variable data part
packed integer：表中欄位個數，這個地方為packed integer自行參考原始碼
uchar *net_store_length或者參考第一章
(解析MYSQL BINLOG 二進位制格式(1)--準備工作 )
var-size:文件解釋為每一位代表是否欄位用到了 長度為INT((n+7)/8) n代表欄位數量
原始碼描述為 m_cols; /* Bitmap denoting columns available */
測試表現這一位元組和binlog_row_image設定有關，預設為FULL每一個位元組始終為
0XFF
var-size-update:UPDATE_ROW_EVENT專用和前面描述的一致，但是表示的是後印象，也就是update後的資料
var-size:每一位代表的欄位的值是否為NULL，長度為INT((n+7)/8) n代表欄位數量，
他採用一個點陣圖的方式。
1：NULL
0：NOT NULL
var-size:這部分就是真正的資料了。
var-size-update:
var-size-update:
這兩部分為UPDATE_ROW_EVENT專用和前面描述的兩部分一致，但是表示的是後印象，也就是update後的資料
接下來進行實際的解析：
執行語句
mysql> select * from testnull2;
+------+-------+-------+
| id | name1 | name2 |
+------+-------+-------+
| NULL | test | NULL |
+------+-------+-------+
1 row in set (0.01 sec)
mysql> update testnull2 set id=2,name2='test',name1=NULL where name1='test';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> delete from testnull2;
Query OK, 1 row affected (0.02 sec)
使用./infobin (自己開發 我放到了雲盤)
[root@testmy data]# ./infobin test.000184
Check is Little_endian
Author: gaopeng QQ:22389860 Mail: gaopp_200217@163.com
Waring: This tool only Little_endian platform!
Little_endian check ok!!!
-------------Now begin--------------
Check Mysql Version is:5.7.13-log
Check Mysql binlog format ver is:V4
------------Detail now--------------
>Gtid Event:Pos:194(0Xc2) N_pos:259(0X103) Time:1486949924 Event_size:65(bytes)
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000450
-->Query Event:Pos:259(0X103) N_Pos:331(0X14b) Time:1486949924 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN
---->Map Event:Pos331(0X14b) N_pos:389(0X185) Time:1486949924 Event_size:58(bytes)
TABLE_ID:210 DB_NAME:test TABLE_NAME:testnull2
------>Update Event:Pos:389(0X185) N_pos is:441(0X1b9) time:1486949924 event_size:52(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000450
>Xid Event:Pos:441(0X1b9) N_Pos:472(0X1d8) Time:1486949924 Event_size:31(bytes)
COMMIT 1000450 /*!add by tool*/
>Gtid Event:Pos:472(0X1d8) N_pos:537(0X219) Time:1486949930 Event_size:65(bytes)
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000451
-->Query Event:Pos:537(0X219) N_Pos:609(0X261) Time:1486949930 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN
---->Map Event:Pos609(0X261) N_pos:667(0X29b) Time:1486949930 Event_size:58(bytes)
TABLE_ID:210 DB_NAME:test TABLE_NAME:testnull2
------>Delete Event:Pos:667(0X29b) N_pos:712(0X2c8) Time:1486949930 Event_size:45(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000451
>Xid Event:Pos:712(0X2c8) N_Pos:743(0X2e7) Time:1486949930 Event_size:31(bytes)
COMMIT 1000451 /*!add by tool*/
可以看到我們的update和delete的位置
------>Update Event:Pos:389(0X185) N_pos is:441(0X1b9) time:1486949924 event_size:52(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000450
------>Delete Event:Pos:667(0X29b) N_pos:712(0X2c8) Time:1486949930 Event_size:45(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000451
現在使用mysqlbinlog --hexdump -vv 進行解析
先來看update event
二進位制解析
# at 389
#170213 9:38:44 server id 93157 end_log_pos 441 CRC32 0x21c0591d
# Position Timestamp Type Master ID Size Master Pos Flags
# 185 24 0e a1 58 1f e5 6b 01 00 34 00 00 00 b9 01 00 00 00 00
# 198 d2 00 00 00 00 00 01 00 02 00 03 ff ff fd 04 74 |...............t|
# 1a8 65 73 74 fa 02 00 00 00 04 74 65 73 74 1d 59 c0 |est......test.Y.|
# 1b8 21 |.|
# Update_rows: table id 210 flags: STMT_END_F
-vv輸出
### UPDATE `test`.`testnull2`
### WHERE
### @1=NULL /* type=3 meta=0 nullable=1 is_null=1 */
### @2='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
### @3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
### SET
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### @2=NULL /* INT meta=60 nullable=1 is_null=1 */
### @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
分解：
--event header 部分就不解析了table id 210，
--hexdump也明確的解析了，不理解參考前面的文章
# Position Timestamp Type Master ID Size Master Pos Flags
# 185 24 0e a1 58 1f e5 6b 01 00 34 00 00 00 b9 01 00 00 00 00
--fixed data
d2 00 00 00 00 00：表ID就是./infobin中的TABLE_ID:210 也是mysqlbinlog中的Update_rows: table id 210
小端顯示
01 00：保留
02 00：m_extra_row_data,這部分是我看原始碼找到的。
--variable data part
03：表中欄位個數，當然我建表就是3個欄位
ff: 原始碼描述為 m_cols; /* Bitmap denoting columns available */
ff：update專用和上面一致
----update前印象資料：
fd: 11111101 代表欄位@1=NULL和@3=NULL，但是欄位@2不為空這和mysqlbinlog解析的一致
@1=NULL /* type=3 meta=0 nullable=1 is_null=1 */
@2='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
@3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
04:var 長度04 就是資料'test'的長度為4，這個也就是@2='test'事update的前印象
74 65 73 74：字串'test'
----update後印象資料(update 專用)：
fa：11111010，@2=NULL，但是修改後@1和@3不為空和mysqlbinlog解析一致
@1=2 /* INT meta=0 nullable=1 is_null=0 */
@2=NULL /* INT meta=60 nullable=1 is_null=1 */
@3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
02 00 00 00 ：也就是資料2也是@1=2也就是update的後印象，小端顯示
04： var 長度04 就是資料'test'的長度為4，也就是
74 65 73 74：字串'test'也是@3='test'也就是update的後印象
1d 59 c0 21：CRC32校驗
然後來看delete event
二進位制解析
# at 667
#170213 9:38:50 server id 93157 end_log_pos 712 CRC32 0x055741c1
# Position Timestamp Type Master ID Size Master Pos Flags
# 29b 2a 0e a1 58 20 e5 6b 01 00 2d 00 00 00 c8 02 00 00 00 00
# 2ae d2 00 00 00 00 00 01 00 02 00 03 ff fa 02 00 00 |................|
# 2be 00 04 74 65 73 74 c1 41 57 05 |..test.AW.|
# Delete_rows: table id 210 flags: STMT_END_F
-vv輸出
### DELETE FROM `test`.`testnull2`
### WHERE
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### @2=NULL /* INT meta=60 nullable=1 is_null=1 */
### @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
分解：
--event header 部分就不解析了table id 210，
--hexdump也明確的解析了，不理解參考前面的文章
# Position Timestamp Type Master ID Size Master Pos Flags
# 185 24 0e a1 58 1f e5 6b 01 00 34 00 00 00 b9 01 00 00 00 00
--fixed data
d2 00 00 00 00 00：表ID就是./infobin中的TABLE_ID:210 也是mysqlbinlog中的Delete_rows: table id 210
小端顯示
01 00：保留
02 00：m_extra_row_data,這部分是我看原始碼找到的。
--variable data part
03：表中欄位個數，當然我建表就是3個欄位
ff: 原始碼描述為 m_cols; /* Bitmap denoting columns available */
fa: 11111010 代表欄位@2=NULL，但是欄位@1 @3不為空這和mysqlbinlog解析的一致
@1=2 /* INT meta=0 nullable=1 is_null=0 */
@2=NULL /* INT meta=60 nullable=1 is_null=1 */
@3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
02 00 00 00: int 4位元組資料 2及@1=2 小端顯示
04:var 長度04 就是資料'test'的長度為4，這個也就是@3='test'
74 65 73 74：字串'test'
c1 41 57 05：crc32 校驗
至此UPDATE_ROW_EVENT和DELETE_ROWS_EVENT解析完畢
後記：
1、在UPDATE_ROW_EVENT/DELETE_ROWS_EVENT/WRITE_ROWS_EVENT中存在一個欄位值是否為空的點陣圖，如前面所說
然後緊跟了欄位資料，這樣根據點陣圖就能確定出那些欄位為NULL，而實際儲存的值中並不包含NULL欄位的資料
因為它沒有資料，同樣也為了減少儲存空間的使用，這種技術在資料庫技術中大量使用，在INNODB PAGES中也
是用到了。
2、很多閃回工具都依賴了binlog中能夠記錄了需要的所有資訊，我們也看到了update還記錄前後印象的值，那麼
也為閃回提供了條件，但是binlog_row_image會影響它的記錄方式具體參考官方手冊，但是它可以節約空間。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7728585/viewspace-2133469/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 解析MYSQL BINLOG二進位制格式(9)--infobin解析binlog幫助文件MySql
- 解析MYSQL BINLOG二進位制格式(10)--問題解答MySql
- 解析MYSQL BINLOG 二進位制格式(1)--準備工作MySql
- 解析MYSQL BINLOG 二進位制格式(3)--QUERY_EVENTMySql
- 解析MYSQL BINLOG 二進位制格式(4)--TABLE_MAP_EVENTMySql
- 解析MYSQL BINLOG 二進位制格式(5)--WRITE_ROW_EVENTMySql
- 解析MYSQL BINLOG 二進位制格式(2)--FORMAT_DESCRIPTION_EVENTMySqlORM
- MySQL二進位制檔案（binlog）MySql
- 解析MYSQL BINLOG 二進位制格式(7)--Xid_log_event/XID_EVENTMySql
- Java二進位制Class檔案格式解析Java
- 解析MYSQL BINLOG二進位制格式(8)--GTID_LOG_EVENT/ANONYMOUS_GTID_LOG_EVENT及其他MySql
- mysql二進位制日誌格式介紹MySql
- 如何在MySQL中檢視binlog二進位制日誌？MySql
- office檔案格式複合文件二進位制結構解析
- MySQL二進位制日誌MySql
- mysql 二進位制日誌MySql
- mixed模式下的binlog二進位制日誌解析，需要加-v引數模式
- 二進位制求5個1的格式。。。。
- Mysql二進位制包安裝MySql
- 管理mysql二進位制日誌MySql
- mysql的二進位制日誌MySql
- 二進位制與二進位制運算
- 進位制詳解：二進位制、八進位制和十六進位制
- JavaScript 二進位制、八進位制與十六進位制JavaScript
- [MySQL binlog]徹底解析Mixed日誌格式的binlogMySql
- MySQL二進位制日誌的三種格式優缺點比較MySql
- MySQL 壓縮二進位制日誌MySql
- mysql二進位制日誌詳解MySql
- MySQL linux二進位制安裝MySqlLinux
- 利用vstruct解析二進位制資料Struct
- （二進位制）
- 十進位制——二 (八、十六 )進位制
- 二進位制，八進位制，十進位制，十六進位制的相互轉換
- 二進位制、十進位制與十六進位制相互轉化
- java中二進位制、八進位制、十進位制、十六進位制的轉換Java
- 二進位制，八進位制，十進位制，十六進位制之間的轉換
- Python 進位制互相轉換（二進位制、十進位制和十六進位制）Python
- 計算機基礎進位制轉換（二進位制、八進位制、十進位制、十六進位制）計算機