這篇文章主要介紹MySQL中insert的問(wèn)題分析，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

創(chuàng)新互聯(lián)專注于企業(yè)網(wǎng)絡(luò)營(yíng)銷推廣、網(wǎng)站重做改版、祁門網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5響應(yīng)式網(wǎng)站、電子商務(wù)商城網(wǎng)站建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)公司、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為祁門等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

image.png

image.png

2、profile展示

image.png

實(shí)際上這里的query end是一個(gè)非常有用的信息，基本確認(rèn)是在order_commit函數(shù)上的等待。

二、問(wèn)題初次分析

在我遇到的案例中有大事物造成的小事物commit慢的情況，且狀態(tài)也是query end，但是這里問(wèn)題顯然不太一樣，如果是大事物造成的會(huì)是偶爾出現(xiàn)commit慢的情況而這里是穩(wěn)定出現(xiàn)等待1秒的情況。但是我還是要朋友采集了binlog的大事物信息使用我的一個(gè)工具如下:

小工具可以分析binlog 的一些信息比如： 1、是否有長(zhǎng)期未提交的事物 2、是否有大事物 3、每個(gè)表生成了多少日志 4、生成速度。
使用:
./infobin  mysql-bin.001793 20 2000000 10 -t >log1793.log 第一個(gè)20 是分片數(shù)量
第二個(gè)2000000 是大于2M左右的事物定義為大事物
第三個(gè)10 是大于10秒未提交的事物定義為長(zhǎng)期未提交的事物 
下載地址:
http://pan.baidu.com/s/1jHIWUN0 只能用于binlog 不能用于relaylog。最好將binlog拷貝其他機(jī)器執(zhí)行，不要在生產(chǎn)服務(wù)器跑
最好是5.6 5.7 row格式binlog

這個(gè)工具是我用C寫的不依賴其他工具解析binlog獲取有用信息的工具，也很多朋友在用。占時(shí)沒有開源，其實(shí)也很簡(jiǎn)單就是分析binlog的event來(lái)獲取有用信息。
得到的簡(jiǎn)化結(jié)果如下:

-------------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)

實(shí)際上我們很容易看到binlog整個(gè)才80M左右確實(shí)包含一個(gè)大事物如下,大約占用了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)

但是大事物只會(huì)在提交的那一刻影響其他事物的提交且狀態(tài)為query end參考我早期的一篇文章
http://blog.itpub.net/7728585/viewspace-2133674/

我們先排除大事物導(dǎo)致的的問(wèn)題。那么到底是什么問(wèn)題呢，有朋友說(shuō)可能是半同步，但是不使用半同步的情況下也一樣。且我覺得半同步的導(dǎo)致慢的狀態(tài)應(yīng)該不是query end 占時(shí)沒有測(cè)試。

三、確認(rèn)問(wèn)題

沒有辦法只能使用pstack進(jìn)行分析，幸運(yùn)的是這個(gè)問(wèn)題確實(shí)簡(jiǎn)單如下的pstack棧幀：

image.png

居然binlog_group_commit_sync_delay設(shè)置為了大值1000000也就是1秒，這也就解釋了為什么簡(jiǎn)單的insert都會(huì)等待1秒了，且狀態(tài)為query end。

以上是“MySQL中insert的問(wèn)題分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道！

當(dāng)前文章：MySQL中insert的問(wèn)題分析-創(chuàng)新互聯(lián)
本文地址：http://www.chinadenli.net/article4/docpoe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站導(dǎo)航、小程序開發(fā)、App設(shè)計(jì)、網(wǎng)站維護(hù)、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)