此讨论仅限于Innodb存储引擎；

DBA与研发人员沟通的时候常常会说 “拒绝大事务，这事务太大啦，拆开”，“你要批量提交”；“什么，批量提交？这岂不是成了一个大事务？”

我根据自己的理解简单说明下,拒绝大事务，批量提交是针对不同“场景”的；

大事务就意味着锁持有的时间比较长（尽管Innodb是行锁）：

缺点:

1、造成锁等待，其他需要同样row的事务处于lock wait状态，加大响应时间；

2、对一张表并发较高的时候，造成死锁几率较高

3、对于replication环境，会造成slave延迟较高（单线程SQL执行更改）

拆分大事务的话基本会提高并发量，降低死锁几率，减小slave延迟，是不是全部采用“小”事务就万事ok啦？

万事没有绝对，对于insert 语句，我有200w行记录，我执行200w次提交，这样事务就足够小啦；

这样并发量很高，基本无死锁，但master 和slave的IO 就快要受不了啦；

首先从SQL语句解析上，就需要解析200w次（暂不考虑使用prepare statement的情况）

其次如果insert字段中包含主键，那基本上是insert 一次，commit一次，就会产生一次IO，也就是会产生>=200w次IO；如果是非主键的话，innodb会利用其 insert buffer,change buffer等就合并IO，但这样做的效率不会显著太多，程序端在不断的insert；可以考虑每次提交2000条，分多次提交；这样就会降低IO利用率，slave可以平稳的过度；

什么时候事务保证足够的并发量，又要降低IO利用率呢，这杆秤还是需要DBA来实时的观察，比如借助zabbix这样优秀的监控工具，监控你的QPS，响应时间，IO利用率适当的调整！

有什么疑问随时讨论！

©著作权归作者所有：来自51CTO博客作者位鹏飞的原创作品，如需转载，请注明出处，否则将追究法律责任

MySQLIO事务数据库