共計 2446 個字符，預計需要花費 7 分鐘才能閱讀完成。
這篇文章主要介紹 MySQL 中 insert 的問題分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！
image.png
image.png
2、profile 展示
image.png
實際上這里的 query end 是一個非常有用的信息，基本確認是在 order_commit 函數上的等待。
二、問題初次分析
在我遇到的案例中有大事物造成的小事物 commit 慢的情況，且狀態也是 query end，但是這里問題顯然不太一樣，如果是大事物造成的會是偶爾出現 commit 慢的情況而這里是穩定出現等待 1 秒的情況。但是我還是要朋友采集了 binlog 的大事物信息使用我的一個工具如下:
小工具可以分析 binlog 的一些信息比如： 1、是否有長期未提交的事物 2、是否有大事物 3、每個表生成了多少日志 4、生成速度。./infobin mysql-bin.001793 20 2000000 10 -t log1793.log 第一個 20 是分片數量
第二個 2000000 是大于 2M 左右的事物定義為大事物
第三個 10 是大于 10 秒未提交的事物定義為長期未提交的事物
下載地址:
http://pan.baidu.com/s/1jHIWUN0 只能用于 binlog 不能用于 relaylog。最好將 binlog 拷貝其他機器執行，不要在生產服務器跑
最好是 5.6 5.7 row 格式 binlog
這個工具是我用 C 寫的不依賴其他工具解析 binlog 獲取有用信息的工具，也很多朋友在用。占時沒有開源，其實也很簡單就是分析 binlog 的 event 來獲取有用信息。
得到的簡化結果如下:
-------------Now begin--------------
Check Mysql Version is:5.7.19-log
Check Mysql binlog format ver is:V4
Warning:Check This binlog is not closed!
Check This binlog total size:87546667(bytes)
Note:load data infile not check!
-------------Total now--------------
Trx total[counts]:42771
Event total[counts]:251792
Max trx event size:9268(bytes) Pos:78378238[0X4ABF4FE]
Avg binlog size(/sec):16745.729(bytes)[16.353(kb)]
Avg binlog size(/min):1004743.688(bytes)[981.195(kb)]
--Large than 2000000(bytes) trx:
(1)Trx_size:54586527(bytes)[53307.156(kb)] trx_begin_p:359790[0X57D6E] trx_end_p:54946317[0X3466A0D]
Total large trx count size(kb):#53307.156(kb) ....
---(79)Current Table:froad_cbank_anhui.cb_sms_log::
Insert:binlog size(824224(Bytes)) times(3135)
Update:binlog size(2046042(Bytes)) times(3841)
Delete:binlog size(0(Bytes)) times(0)
Total:binlog size(2870266(Bytes)) times(6976)
---(80)Current Table:test.2018products::
Insert:binlog size(54586359(Bytes)) times(6647)
Update:binlog size(0(Bytes)) times(0)
Delete:binlog size(0(Bytes)) times(0)
Total:binlog size(54586359(Bytes)) times(6647)
---Total binlog dml event size:73212228(Bytes) times(65090)實際上我們很容易看到 binlog 整個才 80M 左右確實包含一個大事物如下, 大約占用了 50M 多
--Large than 2000000(bytes) trx:
(1)Trx_size:54586527(bytes)[53307.156(kb)] trx_begin_p:359790[0X57D6E] trx_end_p:54946317[0X3466A0D] Total large trx count size(kb):#53307.156(kb)
但是大事物只會在提交的那一刻影響其他事物的提交且狀態為 query end 參考我早期的一篇文章
http://blog.itpub.net/7728585/viewspace-2133674/
我們先排除大事物導致的的問題。那么到底是什么問題呢，有朋友說可能是半同步，但是不使用半同步的情況下也一樣。且我覺得半同步的導致慢的狀態應該不是 query end 占時沒有測試。
三、確認問題
沒有辦法只能使用 pstack 進行分析，幸運的是這個問題確實簡單如下的 pstack 棧幀：
image.png
居然 binlog_group_commit_sync_delay 設置為了最大值 1000000 也就是 1 秒，這也就解釋了為什么簡單的 insert 都會等待 1 秒了，且狀態為 query end。
以上是“MySQL 中 insert 的問題分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注丸趣 TV 行業資訊頻道！
