MYSQL如何識別一個binlog中的一個事物
原創水平有限
測試版本5.7.14
設定GTID_MODE=ON
ON(3): Both new and replicated transactions must be GTID transactions(生成的是GTID事物，slave也只能應用GTID事物)
設定binlog格式為row模式
做如下操作
mysql> insert into test values(1,2);
Query OK, 1 row affected (0.01 sec)
mysql> insert into test values(2,3);
Query OK, 1 row affected (0.01 sec)
mysql> delete from test;
Query OK, 2 rows affected (0.01 sec)
mysql> select * from test;
Empty set (0.00 sec)
首先我透過自己的工具infobin找到了這段操作的binlog，如果想獲得這個工具學習可以參考文章最後
簡單解釋一下這裡 Pos:是當前位置對應mysqlbinlog的 # at 504這裡的N_pos是結束位置對應
mysqlbinlog的 end_log_pos
>Gtid Event:Pos:504(0X1f8) N_pos:569(0X239) Time:1496993578 Event_size:65(bytes)
Gtid:89dfa8a4-cb13-11e6-b54-0c29a879a3:2
-->Query Event:Pos:569(0X239) N_Pos:641(0X281) Time:1496993578 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:2
---->Map Event:Pos641(0X281) N_pos:689(0X2b1) Time:1496993578 Event_size:48(bytes)
TABLE_ID:142 DB_NAME:test TABLE_NAME:test Gno:2
------>Insert Event:Pos:689(0X2b1) N_pos:733(0X2dd) Time:1496993578 Event_size:44(bytes)
Dml on table: test.test table_id:142 Gno:2
>Xid Event:Pos:733(0X2dd) N_Pos:764(0X2fc) Time:1496993578 Event_size:31(bytes)
COMMIT; /*!Trx end*/ Gno:2 --注意這裡以N_Pos為結尾及下一個event的開始位置
>Gtid Event:Pos:764(0X2fc) N_pos:829(0X33d) Time:1496993581 Event_size:65(bytes)
Gtid:89dfa8a4-cb13-11e6-b54-0c29a879a3:3
-->Query Event:Pos:829(0X33d) N_Pos:901(0X385) Time:1496993581 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:3
---->Map Event:Pos901(0X385) N_pos:949(0X3b5) Time:1496993581 Event_size:48(bytes)
TABLE_ID:142 DB_NAME:test TABLE_NAME:test Gno:3
------>Insert Event:Pos:949(0X3b5) N_pos:993(0X3e1) Time:1496993581 Event_size:44(bytes)
Dml on table: test.test table_id:142 Gno:3
>Xid Event:Pos:993(0X3e1) N_Pos:1024(0X400) Time:1496993581 Event_size:31(bytes)
COMMIT; /*!Trx end*/ Gno:3 --注意這裡以N_Pos為結尾及下一個event的開始位置
>Gtid Event:Pos:1024(0X400) N_pos:1089(0X441) Time:1496993584 Event_size:65(bytes)
Gtid:89dfa8a4-cb13-11e6-b54-0c29a879a3:4
-->Query Event:Pos:1089(0X441) N_Pos:1161(0X489) Time:1496993584 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:4
---->Map Event:Pos1161(0X489) N_pos:1209(0X4b9) Time:1496993584 Event_size:48(bytes)
TABLE_ID:142 DB_NAME:test TABLE_NAME:test Gno:4
------>Delete Event:Pos:1209(0X4b9) N_pos:1262(0X4ee) Time:1496993584 Event_size:53(bytes)
Dml on table: test.test table_id:142 Gno:4
>Xid Event:Pos:1262(0X4ee) N_Pos:1293(0X50d) Time:1496993584 Event_size:31(bytes)
COMMIT; /*!Trx end*/ Gno:4 --注意這裡以N_Pos為結尾及下一個event的開始位置
顯然這裡包含了3個事物，
1、504到764為一個事物，工具顯示這個event為Insert Event，在表test.test
2、764到1024為一個事物，工具顯示這個event為Insert Event，在表test.test
3、1024到1293為一個事物，工具顯示這個event為Delete Event，在表test.test
這就是我做的操作，這個工具主要是透過分析binlog event方便尋找事物，當然mysqlbinlog也可以只是輸出有點不直觀。
在透過mysqlbinlog分析的時候一定要注意一個事物的開始和結束。
(mysqlbinlog testsla.000003 -vv --start-postions=504 --stop-postions=1024 --base64-output=decode-rows 檢視不透過base64演算法顯示二進位制內容)
(mysqlbinlog testsla.000003 -vv --start-postions=504 --stop-postions=1024 檢視透過base64演算法顯示二進位制內容）
下面我們透過mysqlbinlog來分析上面的事物1 504到764為
# at 473
#170609 15:20:45 server id 933310 end_log_pos 504 CRC32 0x609296d7 Xid = 161
COMMIT/*!*/; ---注意這裡上一個事物的結束叫做xid event
# at 504 ---這裡是事物1 的起點沒叫做gtid event
#170609 15:32:58 server id 933310 end_log_pos 569 CRC32 0xf7eebfc7 GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '89dfa8a4-cb13-11e6-b504-000c29a879a3:2'/*!*/;
# at 569 ---這段event是query event
#170609 15:32:58 server id 933310 end_log_pos 641 CRC32 0xb4caa78c Query thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1496993578/*!*/;
BEGIN
/*!*/;
# at 641 ---這段event是map event
#170609 15:32:58 server id 933310 end_log_pos 689 CRC32 0xb055655f Table_map: `test`.`test` mapped to number 142
# at 689 ---這段event是insert event
#170609 15:32:58 server id 933310 end_log_pos 733 CRC32 0xd907a353 Write_rows: table id 142 flags: STMT_END_F
### INSERT INTO `test`.`test`
### SET
### @1=1 /* INT meta=0 nullable=1 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 733 --這段event是xid event
#170609 15:32:58 server id 933310 end_log_pos 764 CRC32 0x9dbe0a6b Xid = 323
COMMIT/*!*/; ---這裡是一個事物的結尾叫做xid event，但是注意不是733而是下一個event開始的位置764 或者是 xid event 的end_log_pos ，否則將會被回滾掉
# at 764
#170609 15:33:01 server id 933310 end_log_pos 829 CRC32 0x82aac64c GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '89dfa8a4-cb13-11e6-b504-000c29a879a3:3'/*!*/;
所以我們認為一個事物的binlog是504到764
如果寫為733會出現這種情況
mysqlbinlog testsla.000003 --start-position=504 --stop-position=733 -vv --base64-output=decode-rows
........
# at 689
#170609 15:32:58 server id 933310 end_log_pos 733 CRC32 0xd907a353 Write_rows: table id 142 flags: STMT_END_F
### INSERT INTO `test`.`test`
### SET
### @1=1 /* INT meta=0 nullable=1 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */; --很明顯沒有xid event 沒有commit而mysqlbinlog自己家了一個rollback而回滾掉了
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETI
好這裡我們簡單介紹一個事物binlog event的流程，正如我工具所展示的
>Gtid Event ：事物開始
-->Query Event：begin
---->Map Event ：表對映
------>Insert Event：正真的資料二進位制格式
>Xid Event: commit
這事一個事物需要經歷的event，在5.7中不開啟GTID，GTID EVENT任然存在那叫匿名gtid event及NONYMOUS_GTID_LOG_EVENT，在5.6中
最多gtid event有變動，因為5.6的並行slave不依靠binlog group commit。
如果想了解這些event和infobin工具請參考的文章：
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
http://blog.itpub.net/7728585/viewspace-2133469/ 解析MYSQL BINLOG 二進位制格式(6)--UPDATE_ROW_EVENT/DELETE_ROW_EVENT
http://blog.itpub.net/7728585/viewspace-2133502/ 解析MYSQL BINLOG 二進位制格式(7)--Xid_log_event/XID_EVENT
http://blog.itpub.net/7728585/viewspace-2133506/ 解析MYSQL BINLOG 二進位制格式(8)--GTID_LOG_EVENT/ANONYMOUS_GTID_LOG_EVENT及其他
http://blog.itpub.net/7728585/viewspace-2133534/ 解析MYSQL BINLOG 二進位制格式(9)--infobin解析binlog幫助文件
http://blog.itpub.net/7728585/viewspace-2133537/ 解析MYSQL BINLOG 二進位制格式(10)--問題解答
最後看看語句模式的一個事物，雖然很少人用但是我們做一個對比
>Gtid Event:Pos:194(0Xc2) N_pos:259(0X103) Time:1496998879 Event_size:65(bytes)
Gtid:89dfa8a4-cb13-11e6-b54-0c29a879a3:5
-->Query Event:Pos:259(0X103) N_Pos:338(0X152) Time:1496998879 Event_size:79(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:5
-->Query Event:Pos:338(0X152) N_Pos:428(0X1ac) Time:1496998879 Event_size:90(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):delete from test Gno:5
>Xid Event:Pos:428(0X1ac) N_Pos:459(0X1cb) Time:1496998879 Event_size:31(bytes)
COMMIT; /*!Trx end*/ Gno:5
及
>GTID EVENT :事物開始
-->Query Event :begin
-->Query Event :正真的語句
>Xid Event: commit
沒有Map Event和Insert Event，當然記錄的是語句就節約空間了。
下面是mysqlbinlog輸出
# at 194 --GTID EVENT開始
#170609 17:01:19 server id 933310 end_log_pos 259 CRC32 0x6a408c33 GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '89dfa8a4-cb13-11e6-b504-000c29a879a3:5'/*!*/;
# at 259 --Query Event BEGIN
#170609 17:01:19 server id 933310 end_log_pos 338 CRC32 0x9b25b2af Query thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1496998879/*!*/;
SET @@session.pseudo_thread_id=2/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=83,@@session.collation_connection=83,@@session.collation_server=83/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 338 --Query Event 正真的語句
#170609 17:01:19 server id 933310 end_log_pos 428 CRC32 0x4e4230f8 Query thread_id=2 exec_time=0 error_code=0
use `test`/*!*/;
SET TIMESTAMP=1496998879/*!*/;
delete from test
/*!*/;
# at 428 -- XID EVENT結束
#170609 17:01:19 server id 933310 end_log_pos 459 CRC32 0x38079d60 Xid = 159
COMMIT/*!*/;
作者微信:
測試版本5.7.14
設定GTID_MODE=ON
ON(3): Both new and replicated transactions must be GTID transactions(生成的是GTID事物，slave也只能應用GTID事物)
設定binlog格式為row模式
做如下操作
mysql> insert into test values(1,2);
Query OK, 1 row affected (0.01 sec)
mysql> insert into test values(2,3);
Query OK, 1 row affected (0.01 sec)
mysql> delete from test;
Query OK, 2 rows affected (0.01 sec)
mysql> select * from test;
Empty set (0.00 sec)
首先我透過自己的工具infobin找到了這段操作的binlog，如果想獲得這個工具學習可以參考文章最後
簡單解釋一下這裡 Pos:是當前位置對應mysqlbinlog的 # at 504這裡的N_pos是結束位置對應
mysqlbinlog的 end_log_pos
>Gtid Event:Pos:504(0X1f8) N_pos:569(0X239) Time:1496993578 Event_size:65(bytes)
Gtid:89dfa8a4-cb13-11e6-b54-0c29a879a3:2
-->Query Event:Pos:569(0X239) N_Pos:641(0X281) Time:1496993578 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:2
---->Map Event:Pos641(0X281) N_pos:689(0X2b1) Time:1496993578 Event_size:48(bytes)
TABLE_ID:142 DB_NAME:test TABLE_NAME:test Gno:2
------>Insert Event:Pos:689(0X2b1) N_pos:733(0X2dd) Time:1496993578 Event_size:44(bytes)
Dml on table: test.test table_id:142 Gno:2
>Xid Event:Pos:733(0X2dd) N_Pos:764(0X2fc) Time:1496993578 Event_size:31(bytes)
COMMIT; /*!Trx end*/ Gno:2 --注意這裡以N_Pos為結尾及下一個event的開始位置
>Gtid Event:Pos:764(0X2fc) N_pos:829(0X33d) Time:1496993581 Event_size:65(bytes)
Gtid:89dfa8a4-cb13-11e6-b54-0c29a879a3:3
-->Query Event:Pos:829(0X33d) N_Pos:901(0X385) Time:1496993581 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:3
---->Map Event:Pos901(0X385) N_pos:949(0X3b5) Time:1496993581 Event_size:48(bytes)
TABLE_ID:142 DB_NAME:test TABLE_NAME:test Gno:3
------>Insert Event:Pos:949(0X3b5) N_pos:993(0X3e1) Time:1496993581 Event_size:44(bytes)
Dml on table: test.test table_id:142 Gno:3
>Xid Event:Pos:993(0X3e1) N_Pos:1024(0X400) Time:1496993581 Event_size:31(bytes)
COMMIT; /*!Trx end*/ Gno:3 --注意這裡以N_Pos為結尾及下一個event的開始位置
>Gtid Event:Pos:1024(0X400) N_pos:1089(0X441) Time:1496993584 Event_size:65(bytes)
Gtid:89dfa8a4-cb13-11e6-b54-0c29a879a3:4
-->Query Event:Pos:1089(0X441) N_Pos:1161(0X489) Time:1496993584 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:4
---->Map Event:Pos1161(0X489) N_pos:1209(0X4b9) Time:1496993584 Event_size:48(bytes)
TABLE_ID:142 DB_NAME:test TABLE_NAME:test Gno:4
------>Delete Event:Pos:1209(0X4b9) N_pos:1262(0X4ee) Time:1496993584 Event_size:53(bytes)
Dml on table: test.test table_id:142 Gno:4
>Xid Event:Pos:1262(0X4ee) N_Pos:1293(0X50d) Time:1496993584 Event_size:31(bytes)
COMMIT; /*!Trx end*/ Gno:4 --注意這裡以N_Pos為結尾及下一個event的開始位置
顯然這裡包含了3個事物，
1、504到764為一個事物，工具顯示這個event為Insert Event，在表test.test
2、764到1024為一個事物，工具顯示這個event為Insert Event，在表test.test
3、1024到1293為一個事物，工具顯示這個event為Delete Event，在表test.test
這就是我做的操作，這個工具主要是透過分析binlog event方便尋找事物，當然mysqlbinlog也可以只是輸出有點不直觀。
在透過mysqlbinlog分析的時候一定要注意一個事物的開始和結束。
(mysqlbinlog testsla.000003 -vv --start-postions=504 --stop-postions=1024 --base64-output=decode-rows 檢視不透過base64演算法顯示二進位制內容)
(mysqlbinlog testsla.000003 -vv --start-postions=504 --stop-postions=1024 檢視透過base64演算法顯示二進位制內容）
下面我們透過mysqlbinlog來分析上面的事物1 504到764為
# at 473
#170609 15:20:45 server id 933310 end_log_pos 504 CRC32 0x609296d7 Xid = 161
COMMIT/*!*/; ---注意這裡上一個事物的結束叫做xid event
# at 504 ---這裡是事物1 的起點沒叫做gtid event
#170609 15:32:58 server id 933310 end_log_pos 569 CRC32 0xf7eebfc7 GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '89dfa8a4-cb13-11e6-b504-000c29a879a3:2'/*!*/;
# at 569 ---這段event是query event
#170609 15:32:58 server id 933310 end_log_pos 641 CRC32 0xb4caa78c Query thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1496993578/*!*/;
BEGIN
/*!*/;
# at 641 ---這段event是map event
#170609 15:32:58 server id 933310 end_log_pos 689 CRC32 0xb055655f Table_map: `test`.`test` mapped to number 142
# at 689 ---這段event是insert event
#170609 15:32:58 server id 933310 end_log_pos 733 CRC32 0xd907a353 Write_rows: table id 142 flags: STMT_END_F
### INSERT INTO `test`.`test`
### SET
### @1=1 /* INT meta=0 nullable=1 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 733 --這段event是xid event
#170609 15:32:58 server id 933310 end_log_pos 764 CRC32 0x9dbe0a6b Xid = 323
COMMIT/*!*/; ---這裡是一個事物的結尾叫做xid event，但是注意不是733而是下一個event開始的位置764 或者是 xid event 的end_log_pos ，否則將會被回滾掉
# at 764
#170609 15:33:01 server id 933310 end_log_pos 829 CRC32 0x82aac64c GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '89dfa8a4-cb13-11e6-b504-000c29a879a3:3'/*!*/;
所以我們認為一個事物的binlog是504到764
如果寫為733會出現這種情況
mysqlbinlog testsla.000003 --start-position=504 --stop-position=733 -vv --base64-output=decode-rows
........
# at 689
#170609 15:32:58 server id 933310 end_log_pos 733 CRC32 0xd907a353 Write_rows: table id 142 flags: STMT_END_F
### INSERT INTO `test`.`test`
### SET
### @1=1 /* INT meta=0 nullable=1 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */; --很明顯沒有xid event 沒有commit而mysqlbinlog自己家了一個rollback而回滾掉了
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETI
好這裡我們簡單介紹一個事物binlog event的流程，正如我工具所展示的
>Gtid Event ：事物開始
-->Query Event：begin
---->Map Event ：表對映
------>Insert Event：正真的資料二進位制格式
>Xid Event: commit
這事一個事物需要經歷的event，在5.7中不開啟GTID，GTID EVENT任然存在那叫匿名gtid event及NONYMOUS_GTID_LOG_EVENT，在5.6中
最多gtid event有變動，因為5.6的並行slave不依靠binlog group commit。
如果想了解這些event和infobin工具請參考的文章：
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
http://blog.itpub.net/7728585/viewspace-2133469/ 解析MYSQL BINLOG 二進位制格式(6)--UPDATE_ROW_EVENT/DELETE_ROW_EVENT
http://blog.itpub.net/7728585/viewspace-2133502/ 解析MYSQL BINLOG 二進位制格式(7)--Xid_log_event/XID_EVENT
http://blog.itpub.net/7728585/viewspace-2133506/ 解析MYSQL BINLOG 二進位制格式(8)--GTID_LOG_EVENT/ANONYMOUS_GTID_LOG_EVENT及其他
http://blog.itpub.net/7728585/viewspace-2133534/ 解析MYSQL BINLOG 二進位制格式(9)--infobin解析binlog幫助文件
http://blog.itpub.net/7728585/viewspace-2133537/ 解析MYSQL BINLOG 二進位制格式(10)--問題解答
最後看看語句模式的一個事物，雖然很少人用但是我們做一個對比
>Gtid Event:Pos:194(0Xc2) N_pos:259(0X103) Time:1496998879 Event_size:65(bytes)
Gtid:89dfa8a4-cb13-11e6-b54-0c29a879a3:5
-->Query Event:Pos:259(0X103) N_Pos:338(0X152) Time:1496998879 Event_size:79(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:5
-->Query Event:Pos:338(0X152) N_Pos:428(0X1ac) Time:1496998879 Event_size:90(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):delete from test Gno:5
>Xid Event:Pos:428(0X1ac) N_Pos:459(0X1cb) Time:1496998879 Event_size:31(bytes)
COMMIT; /*!Trx end*/ Gno:5
及
>GTID EVENT :事物開始
-->Query Event :begin
-->Query Event :正真的語句
>Xid Event: commit
沒有Map Event和Insert Event，當然記錄的是語句就節約空間了。
下面是mysqlbinlog輸出
# at 194 --GTID EVENT開始
#170609 17:01:19 server id 933310 end_log_pos 259 CRC32 0x6a408c33 GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '89dfa8a4-cb13-11e6-b504-000c29a879a3:5'/*!*/;
# at 259 --Query Event BEGIN
#170609 17:01:19 server id 933310 end_log_pos 338 CRC32 0x9b25b2af Query thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1496998879/*!*/;
SET @@session.pseudo_thread_id=2/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=83,@@session.collation_connection=83,@@session.collation_server=83/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 338 --Query Event 正真的語句
#170609 17:01:19 server id 933310 end_log_pos 428 CRC32 0x4e4230f8 Query thread_id=2 exec_time=0 error_code=0
use `test`/*!*/;
SET TIMESTAMP=1496998879/*!*/;
delete from test
/*!*/;
# at 428 -- XID EVENT結束
#170609 17:01:19 server id 933310 end_log_pos 459 CRC32 0x38079d60 Xid = 159
COMMIT/*!*/;
作者微信:
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7728585/viewspace-2140595/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 如何在面試中識別一個壞老闆面試
- 如何清晰地表達一個事物、觀點、原理
- 【Mysql】從binlog中找出單個表的binlog資訊MySql
- 如何快速找到MYSQL binlog中的大事物以及生成量分佈(infobin工具)MySql
- 掌握一個事物時所需要學會的
- 【MySQL】一、如何快速執行 binlogMySql
- 建立一個MySQL資料庫中的datetime型別MySql資料庫型別
- 在MySQL中如何有效的刪除一個大表？MySql
- 如何訓練一個簡單的音訊識別網路音訊
- mysql 從一個表中查詢，插入到另一個表中MySql
- jmeter 的兩個介面，變數都是一樣的第一個介面能識別出來，第二個識別不出來，求教大佬JMeter變數
- SAP SEGW 事物碼裡的 ABAP 型別和 EDM 型別對映的一個具體例子型別
- 一個簡單的人臉識別庫
- 自己實現一個 DFA 串模式識別器（一）模式
- MySql Binlog 初識MySql
- 如何將一個陣列中的元素插入另一個陣列陣列
- 一個小工具識別哪個docker佔用gpuDockerGPU
- javascript如何判斷一個物件的型別JavaScript物件型別
- 找一個陣列中特別的數陣列
- 一個簡單的完整人臉識別系統
- MySQL中的這個池子，強的一批！MySql
- TypeScript中，如何利用陣列生成一個聯合型別TypeScript陣列型別
- 如何理解並實現一個簡單的人臉識別演算法（下）：人臉識別演算法
- MYSQL innodb中的只讀事物以及事物id的分配方式MySql
- Java程式碼中，如何監控Mysql的binlog？JavaMySql
- 製作一個Node命令列影象識別工具命令列
- 製作一個Node命令列影像識別工具命令列
- 利用opencv 做一個簡單的人臉識別OpenCV
- 使用 Vala 編寫一個簡單的文字識別程式
- 一條SQL如何被MySQL架構中的各個元件操作執行的？MySql架構元件
- 請教：如何在一個htm頁面中執行一個BeanBean
- [MySQL] MySQL資料庫中唯一識別符號(ID)的梳理總結MySql資料庫符號
- Flutter 中的 ListView 的一個容易忽略的知識點FlutterView
- 利用MySQL全備份（mysqldump），如何只恢復一個庫或者一個表？MySql
- mysql 一個錯誤MySql
- MySQL：一個特殊的問題MySql
- MySQL：一個奇怪的hang案例MySql
- 使用一個Oracle MySQL的理念OracleMySql