此讨论仅限于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利用率适当的调整!
有什么疑问随时讨论!
转载于:https://blog.51cto.com/weipengfei/1314697