MySQL中insert的问题分析
这篇文章主要介绍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的问题分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注创新互联行业资讯频道！
当前名称：MySQL中insert的问题分析
本文网址：http://cdiso.cn/article/pjshdc.html
