如何快速找到MYSQL binlog中的大事物以及生成量分佈(infobin工具)
原創註明出處：
1、問題引出：
某些時候需要判斷binlog中是否有大事物的存在，比如在解決master-slave延遲
高的情況下。一般我們使用mysqlbinlog來找，但是遇到一個問題，使用mysqbinlog
來找比較麻煩，有沒有一個快速的方法呢？當然使用shell指令碼來做一些格式化，也
可以找到，這裡介紹一個工具叫做infobin 來做，是我自己編寫的用C語言完成
2、infobin能做什麼？
--找到你大於你指定大小日誌量的事物，一般定義為大事物，給出了其位置，透過位置就能在mysqlbinlog的輸出
中找到大事物
--找到一個binlog中哪個時間段生成日誌量最多
--解析binlog生成event的分佈，和部分表語句資訊，
--這個binlog檔案每秒日誌的生成量、最大的event大小，總的事物個數等等
3、如何使用
--USAGE:./infobin [binlogfile] [piece] [bigtrxsize]
[binlogfile]:binlog file!
[piece]:how many piece will split,is a Highly balanced histogram,
find which time generate biggest binlog.(must:piece<2000000)
[bigtrxsize](bytes):larger than this size trx will view.(must:trx>256(bytes))
比如我們要分析72mysql-bin.000586中的大於600K左右的大事物，分10個分片
來判斷日誌生成量的週期就可以如下：
./infobin 72mysql-bin.000586 10 600000 > log6.log
這裡著重解析一下
piece:這是分片引數，比如1G的binlog分為10片那麼1片就是100M左右，如果
分片1在100秒內生成，而分片2在10秒內生成，那麼可以說明分片2期間
生成的日誌量更改，實際上就是100M為大小分為10個桶的大小均衡的直方圖
就看哪個片的時間越短就說明這段時間就更忙。
如：
(4)Time:1487561012-1487561480(468(s)) piece:107374204(bytes)[104857.625(kb)]
(5)Time:1487561480-1487562682(1202(s)) piece:107374204(bytes)[104857.625(kb)]
分片5期間生成的日誌量就小，分片4期間生成的日誌量就大，這裡是新紀元時間以來的秒數
可以用LINUX命令換算 如：date -s "@1487035999"
bigtrxsize：這就是這個指定大小binlog生成量將會在最後輸出，注意大小是bytes位元組，因為row
格式的binlog會記錄實際資料，如果是update當然要*2，比如預計資料是每一行是
1000位元組，你想輸出delete大於1000行的事物，那就是大約1000*1000*4/3=1330000(bytes)
左右，如果是update *2即可.
./infobin 72mysql-bin.000586 10 1330000 >log.log
(10 是piece)
這個是一個變參由自己來定義什麼叫做大事物。
4、如何獲取工具
獲取可以透過百度雲盤
獲得，編譯的只有LINUX64版本的
限制：
--只能使用在Little_endian上，編譯是在LINUX gcc編譯的
--load data infile event是沒有檢測的
--不能讀取出row event的語句，因為沒有寫那麼複雜
--可以讀取出statement格式的語句，但是為了簡潔做了35位元組的截斷，方便輸出
這些東西在mysqlbinlog解析中都有。
--5.6，5.7支援，如果要判斷大事物需要使用row格式binlog，否則判斷可能有誤
5、輸出解釋：
輸出一共分為3段
1、now begin部分：
一目瞭然需要說明一點Warning:Check This binlog is not closed!說明這個binlog是當前正在使用binlog
2、Detail now部分：
這部分是一個詳細的binlog event的輸出
--1、
event都以>開始，但是一個事物的event我使用--> ----> ------->來進行區別化更加利於閱讀，如果
仔細研究過event這些event一定不會陌生
--2、
Pos:當前event位置
N_pos:下一個event位置，
Gtid: 當然就是GTID如果是匿名事物就是ANONYMOUS 其GTID為0
Time:新紀元時間以來的秒數 可以用LINUX命令換算 如：date -s "@1487035999"
Event_size：這個event有多大
Gno:gtid的事物號部分，我用來標示它們是一個事物
TABLE_ID：是行格式特有的，這個用來保證slave複製的正確性
Use_db: use database 預設當前在哪個資料下，是query event特有的
DB_NAME: 這是map event特有的，也是行格式特有的，記錄的是表所在的資料庫，和Use_db有區別，
Statment(35b-trun)：在query event中記錄的語句為了方便輸出將語句做35位元組階段
/*!Trx begin!*/：表示這是一個事物的開始，如果是gtid模式需要向前推一個event，因為gtid event也算到事物中
/*!Trx end*/：自然就是事物的結束點
mysqlbinlog中也是一致的比如：
>Gtid Event:Pos:194(0Xc2) N_pos:259(0X103) Time:1487035999 Event_size:65(bytes)
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1100463
[root@testmy ~]# date -s "@1487035999"
Tue Feb 14 09:33:19 CST 2017
對應mysqlbinlog的如下部分：
# at 194
#170214 9:33:19 server id 93157 end_log_pos 259 CRC32 0xb664a0c6 GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '4a6f2a67-5d87-11e6-a6bd-000c29a879a3:1100463'/*!*/;
3、Total now部分：
這部分是最後的彙總，給出了：
Trx total[counts]: 總的事物個數
Event total[counts]: 總的event個數
Avg binlog size(/sec):平均每秒生成的binlog大小
Avg binlog size(/min):平均每分生成的binlog大小
----Piece view:根據使用者指定piece大小得到一個高度均衡直方圖，這個直方圖用於發現是否有某個時間段生成binlog特別大，
----Large than xxx(bytes) trx:大約xxx BYTES個事，最後會有一個彙總，這部分給出了大事物的開始位置trx_begin_p
結束的位置trx_end_p
列子如下：
-------------Total now--------------
Trx total[counts]:592420
Event total[counts]:3788611
Max trx event size:14344(bytes) Pos:858067571[0X33251273]
Avg binlog size(/sec):261251.109(bytes)[255.128(kb)]
Avg binlog size(/min):15675067.000(bytes)[15307.683(kb)]
--Piece view:
(1)Time:1487560299-1487560543(244(s)) piece:107374204(bytes)[104857.625(kb)]
(2)Time:1487560543-1487560751(208(s)) piece:107374204(bytes)[104857.625(kb)]
(3)Time:1487560751-1487561012(261(s)) piece:107374204(bytes)[104857.625(kb)]
(4)Time:1487561012-1487561480(468(s)) piece:107374204(bytes)[104857.625(kb)]
(5)Time:1487561480-1487562682(1202(s)) piece:107374204(bytes)[104857.625(kb)]
(6)Time:1487562682-1487563492(810(s)) piece:107374204(bytes)[104857.625(kb)]
(7)Time:1487563492-1487563723(231(s)) piece:107374204(bytes)[104857.625(kb)]
(8)Time:1487563723-1487563951(228(s)) piece:107374204(bytes)[104857.625(kb)]
(9)Time:1487563951-1487564159(208(s)) piece:107374204(bytes)[104857.625(kb)]
(10)Time:1487564159-1487564409(250(s)) piece:107374204(bytes)[104857.625(kb)]
--Large than 700000(bytes) trx:
(1)Trx_size:719621(bytes)[702.755(kb)] trx_begin_p:60579814[0X39C5FE6] trx_end_p:61299435[0X3A75AEB]
(2)Trx_size:719771(bytes)[702.901(kb)] trx_begin_p:177760551[0XA986927] trx_end_p:178480322[0XAA364C2]
(3)Trx_size:719779(bytes)[702.909(kb)] trx_begin_p:314334603[0X12BC5D8B] trx_end_p:315054382[0X12C7592E]
(4)Trx_size:719803(bytes)[702.933(kb)] trx_begin_p:317542845[0X12ED51BD] trx_end_p:318262648[0X12F84D78]
(5)Trx_size:719811(bytes)[702.940(kb)] trx_begin_p:367838322[0X15ECC472] trx_end_p:368558133[0X15F7C035]
(6)Trx_size:719765(bytes)[702.896(kb)] trx_begin_p:370735395[0X1618F923] trx_end_p:371455160[0X1623F4B8]
(7)Trx_size:719755(bytes)[702.886(kb)] trx_begin_p:433385835[0X19D4F16B] trx_end_p:434105590[0X19DFECF6]
(8)Trx_size:719827(bytes)[702.956(kb)] trx_begin_p:446989814[0X1AA485F6] trx_end_p:447709641[0X1AAF81C9]
(9)Trx_size:719973(bytes)[703.099(kb)] trx_begin_p:748301414[0X2C9A2C66] trx_end_p:749021387[0X2CA528CB]
(10)Trx_size:719827(bytes)[702.956(kb)] trx_begin_p:915609664[0X36931840] trx_end_p:916329491[0X369E1413]
(11)Trx_size:719765(bytes)[702.896(kb)] trx_begin_p:918974063[0X36C66E6F] trx_end_p:919693828[0X36D16A04]
(12)Trx_size:719797(bytes)[702.927(kb)] trx_begin_p:1029346825[0X3D5A9609] trx_end_p:1030066622[0X3D6591BE]
Total large trx count size(kb):#8435.053(kb)
一目瞭然，明顯Time:1487561480-1487562682(1202(s)) Time:1487562682-1487563492(810(s))
這個時間段生成的日誌量較少，其他時間段都比較多。平均大約15307.683(kb)每分鐘的日誌生成量
如果需要分析第一個大事物是什麼只需要在mysqlbinlog的輸出中找到位置60579814這個地方看看是什麼了。
mysqlbinlog --base64-output='decode-rows' -vv --start-position=60579814 --stop-position=61299435 72mysql-bin.000586 >log.log
即可，注意這裡少了一個生成gtid的event的如果要找gtid在前面一個event，這樣是不是簡單多了？
如果要學習binlog 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
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)--問題解答
作者微信：
1、問題引出：
某些時候需要判斷binlog中是否有大事物的存在，比如在解決master-slave延遲
高的情況下。一般我們使用mysqlbinlog來找，但是遇到一個問題，使用mysqbinlog
來找比較麻煩，有沒有一個快速的方法呢？當然使用shell指令碼來做一些格式化，也
可以找到，這裡介紹一個工具叫做infobin 來做，是我自己編寫的用C語言完成
2、infobin能做什麼？
--找到你大於你指定大小日誌量的事物，一般定義為大事物，給出了其位置，透過位置就能在mysqlbinlog的輸出
中找到大事物
--找到一個binlog中哪個時間段生成日誌量最多
--解析binlog生成event的分佈，和部分表語句資訊，
--這個binlog檔案每秒日誌的生成量、最大的event大小，總的事物個數等等
3、如何使用
--USAGE:./infobin [binlogfile] [piece] [bigtrxsize]
[binlogfile]:binlog file!
[piece]:how many piece will split,is a Highly balanced histogram,
find which time generate biggest binlog.(must:piece<2000000)
[bigtrxsize](bytes):larger than this size trx will view.(must:trx>256(bytes))
比如我們要分析72mysql-bin.000586中的大於600K左右的大事物，分10個分片
來判斷日誌生成量的週期就可以如下：
./infobin 72mysql-bin.000586 10 600000 > log6.log
這裡著重解析一下
piece:這是分片引數，比如1G的binlog分為10片那麼1片就是100M左右，如果
分片1在100秒內生成，而分片2在10秒內生成，那麼可以說明分片2期間
生成的日誌量更改，實際上就是100M為大小分為10個桶的大小均衡的直方圖
就看哪個片的時間越短就說明這段時間就更忙。
如：
(4)Time:1487561012-1487561480(468(s)) piece:107374204(bytes)[104857.625(kb)]
(5)Time:1487561480-1487562682(1202(s)) piece:107374204(bytes)[104857.625(kb)]
分片5期間生成的日誌量就小，分片4期間生成的日誌量就大，這裡是新紀元時間以來的秒數
可以用LINUX命令換算 如：date -s "@1487035999"
bigtrxsize：這就是這個指定大小binlog生成量將會在最後輸出，注意大小是bytes位元組，因為row
格式的binlog會記錄實際資料，如果是update當然要*2，比如預計資料是每一行是
1000位元組，你想輸出delete大於1000行的事物，那就是大約1000*1000*4/3=1330000(bytes)
左右，如果是update *2即可.
./infobin 72mysql-bin.000586 10 1330000 >log.log
(10 是piece)
這個是一個變參由自己來定義什麼叫做大事物。
4、如何獲取工具
獲取可以透過百度雲盤
獲得，編譯的只有LINUX64版本的
限制：
--只能使用在Little_endian上，編譯是在LINUX gcc編譯的
--load data infile event是沒有檢測的
--不能讀取出row event的語句，因為沒有寫那麼複雜
--可以讀取出statement格式的語句，但是為了簡潔做了35位元組的截斷，方便輸出
這些東西在mysqlbinlog解析中都有。
--5.6，5.7支援，如果要判斷大事物需要使用row格式binlog，否則判斷可能有誤
5、輸出解釋：
輸出一共分為3段
1、now begin部分：
一目瞭然需要說明一點Warning:Check This binlog is not closed!說明這個binlog是當前正在使用binlog
2、Detail now部分：
這部分是一個詳細的binlog event的輸出
--1、
event都以>開始，但是一個事物的event我使用--> ----> ------->來進行區別化更加利於閱讀，如果
仔細研究過event這些event一定不會陌生
--2、
Pos:當前event位置
N_pos:下一個event位置，
Gtid: 當然就是GTID如果是匿名事物就是ANONYMOUS 其GTID為0
Time:新紀元時間以來的秒數 可以用LINUX命令換算 如：date -s "@1487035999"
Event_size：這個event有多大
Gno:gtid的事物號部分，我用來標示它們是一個事物
TABLE_ID：是行格式特有的，這個用來保證slave複製的正確性
Use_db: use database 預設當前在哪個資料下，是query event特有的
DB_NAME: 這是map event特有的，也是行格式特有的，記錄的是表所在的資料庫，和Use_db有區別，
Statment(35b-trun)：在query event中記錄的語句為了方便輸出將語句做35位元組階段
/*!Trx begin!*/：表示這是一個事物的開始，如果是gtid模式需要向前推一個event，因為gtid event也算到事物中
/*!Trx end*/：自然就是事物的結束點
mysqlbinlog中也是一致的比如：
>Gtid Event:Pos:194(0Xc2) N_pos:259(0X103) Time:1487035999 Event_size:65(bytes)
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1100463
[root@testmy ~]# date -s "@1487035999"
Tue Feb 14 09:33:19 CST 2017
對應mysqlbinlog的如下部分：
# at 194
#170214 9:33:19 server id 93157 end_log_pos 259 CRC32 0xb664a0c6 GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '4a6f2a67-5d87-11e6-a6bd-000c29a879a3:1100463'/*!*/;
3、Total now部分：
這部分是最後的彙總，給出了：
Trx total[counts]: 總的事物個數
Event total[counts]: 總的event個數
Avg binlog size(/sec):平均每秒生成的binlog大小
Avg binlog size(/min):平均每分生成的binlog大小
----Piece view:根據使用者指定piece大小得到一個高度均衡直方圖，這個直方圖用於發現是否有某個時間段生成binlog特別大，
----Large than xxx(bytes) trx:大約xxx BYTES個事，最後會有一個彙總，這部分給出了大事物的開始位置trx_begin_p
結束的位置trx_end_p
列子如下：
-------------Total now--------------
Trx total[counts]:592420
Event total[counts]:3788611
Max trx event size:14344(bytes) Pos:858067571[0X33251273]
Avg binlog size(/sec):261251.109(bytes)[255.128(kb)]
Avg binlog size(/min):15675067.000(bytes)[15307.683(kb)]
--Piece view:
(1)Time:1487560299-1487560543(244(s)) piece:107374204(bytes)[104857.625(kb)]
(2)Time:1487560543-1487560751(208(s)) piece:107374204(bytes)[104857.625(kb)]
(3)Time:1487560751-1487561012(261(s)) piece:107374204(bytes)[104857.625(kb)]
(4)Time:1487561012-1487561480(468(s)) piece:107374204(bytes)[104857.625(kb)]
(5)Time:1487561480-1487562682(1202(s)) piece:107374204(bytes)[104857.625(kb)]
(6)Time:1487562682-1487563492(810(s)) piece:107374204(bytes)[104857.625(kb)]
(7)Time:1487563492-1487563723(231(s)) piece:107374204(bytes)[104857.625(kb)]
(8)Time:1487563723-1487563951(228(s)) piece:107374204(bytes)[104857.625(kb)]
(9)Time:1487563951-1487564159(208(s)) piece:107374204(bytes)[104857.625(kb)]
(10)Time:1487564159-1487564409(250(s)) piece:107374204(bytes)[104857.625(kb)]
--Large than 700000(bytes) trx:
(1)Trx_size:719621(bytes)[702.755(kb)] trx_begin_p:60579814[0X39C5FE6] trx_end_p:61299435[0X3A75AEB]
(2)Trx_size:719771(bytes)[702.901(kb)] trx_begin_p:177760551[0XA986927] trx_end_p:178480322[0XAA364C2]
(3)Trx_size:719779(bytes)[702.909(kb)] trx_begin_p:314334603[0X12BC5D8B] trx_end_p:315054382[0X12C7592E]
(4)Trx_size:719803(bytes)[702.933(kb)] trx_begin_p:317542845[0X12ED51BD] trx_end_p:318262648[0X12F84D78]
(5)Trx_size:719811(bytes)[702.940(kb)] trx_begin_p:367838322[0X15ECC472] trx_end_p:368558133[0X15F7C035]
(6)Trx_size:719765(bytes)[702.896(kb)] trx_begin_p:370735395[0X1618F923] trx_end_p:371455160[0X1623F4B8]
(7)Trx_size:719755(bytes)[702.886(kb)] trx_begin_p:433385835[0X19D4F16B] trx_end_p:434105590[0X19DFECF6]
(8)Trx_size:719827(bytes)[702.956(kb)] trx_begin_p:446989814[0X1AA485F6] trx_end_p:447709641[0X1AAF81C9]
(9)Trx_size:719973(bytes)[703.099(kb)] trx_begin_p:748301414[0X2C9A2C66] trx_end_p:749021387[0X2CA528CB]
(10)Trx_size:719827(bytes)[702.956(kb)] trx_begin_p:915609664[0X36931840] trx_end_p:916329491[0X369E1413]
(11)Trx_size:719765(bytes)[702.896(kb)] trx_begin_p:918974063[0X36C66E6F] trx_end_p:919693828[0X36D16A04]
(12)Trx_size:719797(bytes)[702.927(kb)] trx_begin_p:1029346825[0X3D5A9609] trx_end_p:1030066622[0X3D6591BE]
Total large trx count size(kb):#8435.053(kb)
一目瞭然，明顯Time:1487561480-1487562682(1202(s)) Time:1487562682-1487563492(810(s))
這個時間段生成的日誌量較少，其他時間段都比較多。平均大約15307.683(kb)每分鐘的日誌生成量
如果需要分析第一個大事物是什麼只需要在mysqlbinlog的輸出中找到位置60579814這個地方看看是什麼了。
mysqlbinlog --base64-output='decode-rows' -vv --start-position=60579814 --stop-position=61299435 72mysql-bin.000586 >log.log
即可，注意這裡少了一個生成gtid的event的如果要找gtid在前面一個event，這樣是不是簡單多了？
如果要學習binlog 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
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)--問題解答
作者微信：
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7728585/viewspace-2133985/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 如何通過binlog 輕鬆的找到沒有及時提交的事物(infobin工具)
- MYSQL如何識別一個binlog中的一個事物MySql
- 如何處理IN_DOUBT的分佈事物
- MYSQL innodb中的只讀事物以及事物id的分配方式MySql
- 解析MYSQL BINLOG二進位制格式(9)--infobin解析binlog幫助文件MySql
- 【MySQL】如何快速執行 binlogMySql
- 【MySQL】一、如何快速執行 binlogMySql
- 如何生成指定分佈的隨機數隨機
- Java程式碼中，如何監控Mysql的binlog？JavaMySql
- 如何快速學習複雜事物的指南 - BaldauLDA
- MySQL中redo log、undo log、binlog關係以及區別MySql
- MySQL：如何對待分佈偏移的資料MySql
- 如何使用 ST05 事物碼，快速找到訪問指定資料庫表的 ABAP 程式碼試讀版資料庫
- 【Mysql】從binlog中找出單個表的binlog資訊MySql
- MySQL是如何實現事物隔離？MySql
- MySQL Binlog 解析工具 Maxwell 詳解MySql
- MySQL如何快速獲取binlog的開始時間和結束時間MySql
- 如何在Python中實現這五類強大的概率分佈Python概率分佈
- MySQL中3種清除binlog的方法!MySql
- MYSQL下如何安全的快速刪除大表MySql
- 監聽MySQL的binlog日誌工具分析：CanalMySql
- mysql閃回工具binlog2sqlMySql
- MySQL必知必會：簡介undo log、truncate、以及undo log如何幫你回滾事物MySql
- 分開分表 分散式事物分散式
- 3分鐘部署mysql並開啟binlogMySql
- MySQL中binlog cache使用流程解惑MySql
- 基於JS快速生成各種網格佈局工具Grid介紹JS
- 大資料量的報表如何快速分頁呈現？大資料
- Mysql的binlog原理MySql
- mysql的binlog格式MySql
- 分享生成go的mysql orm工具GoMySqlORM
- 如何快速生成JavaScript文件JavaScript
- 如何在瀏覽器中的網路控制中快速找到傳送到後端的請求瀏覽器後端
- 找到 MySQL 資料庫中的不良索引MySql資料庫索引
- 在統計學中機率分佈中的機率密度函式PDF，機率質量PMF，累積分佈CD函式
- MySQL中binlog備份指令碼分享MySql指令碼
- MySQL工具之binlog2sql閃回操作MySql
- MySQL閃回技術之binlog2sql恢復binlog中的SQLMySql