这篇文章主要讲解了“mysql autocommit=0引起的业务hang住问题分析”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“mysql autocommit=0引起的业务hang住问题分析”吧！

背景

有用户报告一个普通的select语句被hang住了，执行超时。查明之后发现是autocommit使用不当导致。这里将case简化，说明复现步骤及原因。

复现

session1建表并插入数据：createtableifnotexistst(idintprimarykey,cint);setautocommit=0;insertintotvalues(1,1);insertintotvalues(2,2);insertintotvalues(3,3);commit;selectcount(*)fromt;这个执行流程的目的很直观，建表、插入数据、查询结果。貌似没有问题。维持session1不断，新建一个连接session2，执行createtableifnotexistst(idintprimarykey,cint);此时该语句处于等待状态.再新建一个连接session3,执行selectcount(*)fromt;该语句处于等待状态.于是从业务上看就是一个select语句被hang住。

原因分析

MySQLTips:如果服务中某些语句无法执行完成，追查问题时第一步要先保留现场，pstack<pidofmysqld>>tmplog之一个常用的方法。

这两个等待线程的栈如：#00x000000310ce0b7bbinpthread_cond_timedwait@@GLIBC_2.3.2()from/lib64/libpthread.so.0#10x000000000063ba46inMDL_wait::timed_wait(THD*,timespec*,bool,charconst*)()#20x000000000063e095inMDL_context::acquire_lock(MDL_request*,unsignedlong)()可以看到，堵在MDL_wait.简单说明下什么是MDL。试想，如果一个语句在执行一个表上的查询过程中，表结构被改了，或者表被drop，这样会得到一个错误的结果。因此在一个事务持续期间，就需要对访问的表结构作保护。这个就是metadatalock(MDL).很容易理解的，对表数据作增删改查，需要对MDL加读锁，修改表结构、删除表等操作则加写锁。

MySQLTips:MDL是5.5才加入的机制，5.1版本下本文的case不会复现。MySQLTips:事务中MDL申请时机是在首次使用时，释放时机是在事务结束后。

也就是说文章开头的这个case，原因是session2等待在加写锁过程。而session3虽然只是加读锁，但与session2冲突，也需要等待。

session1的事务

也就是说session1还持有表t的MDL读锁。但我们的事务明明已经提交(commit)了。这里就涉及到一个常见的误解。以前有看过文章说，可以用setautocommit=0开启一个事务。其实这个描述不准确.

MySQLTips:setautocommit=0是将本线程设置为非自动提交模式。在每个事务结束后，下个语句开始时自动新建一个事务。

这就意味着，session1最后的那个selectcount(*)操作，实际上之前隐含了一个begin操作。由于该事务没有提交，因此session1持有表t的MDL读锁。因此对于业务方的建议就是，及时提交这些读事务，或断开连接。

MySQLTips:连接断开时，MySQL会自动回滚当前未提交的事务。由于本case里面session1的最后一个事务只是一个select语句，因此回滚不影响业务。

感谢各位的阅读，以上就是“mysql autocommit=0引起的业务hang住问题分析”的内容了，经过本文的学习后，相信大家对mysql autocommit=0引起的业务hang住问题分析这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！