【MySQL】MySQL锁和隔离级别浅析二 之 INSERT

最近在整理线上性能时,发现一台线上DB出现两个insert产生的死锁问题

------------------------
LATEST DETECTED DEADLOCK
------------------------
150119 10:55:08
*** (1) TRANSACTION:
TRANSACTION 578E79C8, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 7 lock struct(s), heap size 1248, 4 row lock(s), undo log entries 5
MySQL thread id 32094912, query id 2210940713 10.10.10.2 database_1 update
insert into table_1
                 (DATA_KEY,JOB_TYPE,FAILURE_QTY,OPT_STATUS,WAVE_NO,BIZ_TYPE,ORG_NO,DISTRIBUTE_NO,WAREHOUSE_NO,CREATE_TIME,UPDATE_TIME,CREATE_USER,UPDATE_USER,YN, REGION)
                 values                  (‘8204593954‘,1009,0,0,‘BC38015011900000062‘,10,‘3‘,‘3‘,‘80‘,now(),null,‘taskAssign-sys‘,null,0,6)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 2784161 n bits 376 index `unique` of table `database_1`.`table_1` trx id 578E79C8 lock mode S waiting
Record lock, heap no 308 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 10; hex 38323034353933393534; asc 8204593954;;
 1: len 19; hex 42433338303135303131393030303030303632; asc BC38015011900000062;;
 2: len 4; hex 800003f1; asc     ;;
 3: len 8; hex 8000000000894c76; asc       Lv;;

*** (2) TRANSACTION:
TRANSACTION 578E79CA, ACTIVE 0 sec inserting, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
7 lock struct(s), heap size 1248, 4 row lock(s), undo log entries 8
MySQL thread id 32094907, query id 2210940717 10.10.10.2 database_1 update
insert into table_1
                (DATA_KEY,JOB_TYPE,FAILURE_QTY,OPT_STATUS,WAVE_NO,BIZ_TYPE,ORG_NO,DISTRIBUTE_NO,WAREHOUSE_NO,CREATE_TIME,UPDATE_TIME,CREATE_USER,UPDATE_USER,YN, REGION)
                 values                 (‘8204593814‘,1009,0,0,‘BC38015011900000062‘,10,‘3‘,‘3‘,‘80‘,now(),null,‘taskAssign-sys‘,null,0,8)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 2784161 n bits 376 index `unique` of table `database_1`.`table_1` trx id 578E79CA lock_mode X locks rec but not gap
Record lock, heap no 308 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 10; hex 38323034353933393534; asc 8204593954;;
 1: len 19; hex 42433338303135303131393030303030303632; asc BC38015011900000062;;
 2: len 4; hex 800003f1; asc     ;;
 3: len 8; hex 8000000000894c76; asc       Lv;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 2784161 n bits 376 index `index_otm_unique` of table `database_1`.`table_1` trx id 578E79CA lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 308 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 10; hex 38323034353933393534; asc 8204593954;;
 1: len 19; hex 42433338303135303131393030303030303632; asc BC38015011900000062;;
 2: len 4; hex 800003f1; asc     ;;
 3: len 8; hex 8000000000894c76; asc       Lv;;

*** WE ROLL BACK TRANSACTION (1)

表结构

primary(id)unique(DATA_KEY,WAVE_NO,JOB_TYPE)
idx_update_time(update_time)
idx_create_time(create_time)

死锁本质原因是由于两个事务以相反顺序锁住了相同的数据,如下图:

对于上面两个insert产生的死锁,分析一下insert锁上面的逻辑:

姜承尧《MySQL内核.InnoDB存储引擎》中对于插入的说明(目录节点9.7.1 插入):

对InnoDB存储引擎表进行插入操作时,需进行如下步骤的操作:
1.首先对表加上IX表。(应该是IX锁)
2.根据查询模式PAGE_CUR_LE定位记录next_rec。
3.判断记录next_rec是否有锁,有的话等待锁的释放,否则直接插入。
插入操作需要定位插入记录的下一条记录,这是next-key locking算法所要求,因为该算法下锁定的不仅仅是记录本身,锁定的是区间。
例如下面的记录:
1、2、3、4、5、7、8
若要插入6这个记录,首先根据查询模式PAGE_CUR_LE定位到记录5,接着判断5这条记录的下一条记录是否有锁,因为如果有锁,则根据next-key locking算法,其表示锁定的范围是:(5,7]或者是(5,7)(gap标志位为1)。因此若记录7上有锁,则不允许在这个范围内进行插入操作。所以插入记录6的操作将被阻塞。对于InnoDB存储引擎而言,若记录next_rec上没有锁,则直接插入,不产生任何的锁对象。否则调用函数lock_rec_enqueue_waiting,等待记录next_rec上锁的释放,这时会产生锁的对象,锁定的记录为next_rec,锁的类型为LOCK_X|LOCK_GAP。
此外,若下一条记录next_rec上有锁,不管持有该锁是否为插入操作事务本身,当插入操作完成后(无需事务提交),需要调用函数lock_update_insert来更新锁定的范围。例如上面的例子,若插入了6这条记录,则原来锁定的范围从(5,7]更新为了(5,6),(6,7]。这样就阻止了其他事物在(5,6)的范围内进行插入操作。
还需要注意的是,若插入的表上有辅助索引,那么还需要对辅助索引记录进行锁的判断,其方法与步骤2、步骤3相同。只是在判断可以进行插入后,还需要更新辅助索引页page header中PAGE_MAX_TRX_ID的值。
函数lock_rec_insert_check_and_lock用来判断next_rec上的锁,参数inherit用来判断是否在插入完成后调用函数lock_update_insert来对已经锁定的范围进行更新。

姜承尧《MySQL技术内幕.InnoDB存储引擎》中对于自增长字段与锁的说明(第一版6.2.4,第二版6.3.4):

自增长在数据库中是非常常见的一种属性,也是很多DBA或开发人员首选的主键方式。在InnoDB存储引擎的内存结构中,对每个含有自增长值的表都有一个自增长计数器(auto-increment counter)。当对含有自增长计数器的表进行插入时,这个计数器会被初始化,会执行如下的语句来得到计数器的值:
”SELECT MAX(auto_inc_col) FROM t FOR UPDATE;”
插入操作会更具这个自增长的计数器值加1赋予自增长列,这个实现方式叫做AUTO-INC Locking。这种锁其实是采用一种特殊的表锁机制,为了提高插入的性能,锁不是在一个事务完成后才释放,而是在完成对自增长值插入的SQL语句后立即释放。
虽然AUTO-INC Locking从一定程度上提高了并发插入的效率,但这里还是存在一些问题。首先,对于有自增长值的列的并发插入性能较差,所以必须等待前一个插入的完成(虽然不用等待事务的完成)。其次,对于INSERT...SELECT的大数据量的插入,会影响插入的性能,因为另一个事务中的插入会被阻塞。
从MySQL 5.1.22版本开始,InnoDB存储引擎提供了一种轻量级互斥量的自增长实现机制,这种机制大大提高了自增长值插入的性能。并且从MySQL 5.1.22开始,InnoDB存储引擎提供了一个参数    innodb_autoinc_lock_mode,默认值为1。在继续讨论新的自增长实现方式之前,我们需要对自增长的插入进行分类:
~INSERT-like:INSERT-like指所有的插入语句,如INSERT、REPLACE、INSERT...SELECT、RELPACE...SELECT、LOAD DATA等
~Simple inserts:Simple inserts指能在插入前就确定插入行数的语句。这些语句包括INSERT、REPLACE等。需要注意的是:Simple inserts不包含INSERT...ON DUPLICATE KEY UPDATE这类SQL语句。
~Bulk inserts:Bulk inserts指在插入前不能确定得到插入行数的语句,如INSERT...SELECT,REPLACE...SELECT,LOAD DATA。
~Mixed-mode inserts:Mixed-mode inserts指插入中有一部分的值时自增长的。有一部分是确定的,如:INSERT INTO t1(c1,c2) VALUES (1,‘a‘),(NULL,‘b‘),(5,‘c‘),(NULL,‘d‘),也可以是指INSERT...ON DUPLICATE KEY UPDATE这类SQL语句。
参数innodb_autoinc_lock_mode有三个可选值,无法动态修改:
##innodb_autoinc_lock_mode=0 这是5.1.22版本之前自增长的实现方式,即通过表锁的AUTO-INC Locking方式。因为有了新的自增长实现方式,所以0这个选项不应该是你的首选项。##innodb_autoinc_lock_mode=1 这是该参数的默认值。对于“SIMPLE INSERT”,该值会用互斥量(mutex)去对内存中的计数器进行累加的操作。对于“BULK INSERT”,还是使用传统的表锁的AUTO-INC Locking方式。这样做,如果不考虑回滚操作,对于自增长的增长还是连续的。而且这种方式下,Statement-Based方式的Replication还是能很好的工作,需要注意的是,如果已经使用AUTO-INC Locking的方式产生自增长的值,而这时需要再进行“SIMPLE INSERT”的操作时,还是要等待AUTO-INC Locking的释放。
##innodb_autoinc_lock_mode=2 在这个模式下,对于所有的“INSERT-like”自增长值的产生都是通过互斥量,而不是AUTO-INC Locking的方式。显然,这是最高性能的方式。然而,这会带来一定的问题。因为并发插入的存在,所以每次插入时,自增长的值可能不是连续的。此外,最重要的是,基于Statement-Based Replication会出现问题。因此,使用这个模式,任何时候都应该使用Row-Base Replication。这样才能保证最大的并发性能和Replication数据的同步。
对于自增长另外需要注意的是,InnoDB存储引擎中的实现和MyISAM不同,MyISAM是表锁的,自增长不用考虑并发插入的问题,因此在Master用InnoDB存储引擎,Slave用MyISAM存储引擎的Replication架构下你必须考虑这种情况。
另外,InnoDB存储引擎下,自增长值的列必须是索引,并且是索引的第一列,如果是第二个列则会报错;而MyISAM存储引擎则没有这个问题。
时间: 2024-10-05 21:38:09

【MySQL】MySQL锁和隔离级别浅析二 之 INSERT的相关文章

【MySQL】MySQL锁和隔离级别浅析一

参考:http://imysql.cn/2008_07_10_innodb_tx_isolation_and_lock_mode 本文只是对于"SELECT ... LOCK IN SHARE MODE"和"SELECT ... FORUPDATE"事务中的锁和RR隔离级别内的测试,针对于表结构.索引结构以及其他隔离级别情况下的触发锁类型,可以参考网易何登成网盘中"MySQL 加锁处理分析.pdf"这篇文章,很细致. 何登成百度网盘:http:/

理解MySql的锁&事务隔离级别

这几篇文章是从网上(http://www.hollischuang.com)看到的一系列文章,也是重温了一下数据库的相关知识.下面是对这些文章的一些前后行文逻辑的说明: 我们知道,在DBMS的多个事业并发执行时,存在着脏读.不可重复读.幻读等情况. 为了解决这些问题,DBMS产品都会通过锁来实现数据库隔离级别从而解决上面的问题. 数据库的读现象浅析 :分析了脏读 & 不可重复读 & 幻读等情况. 数据库的锁机制 : 分析了常见的锁机制,划分了常见的锁分类. MySQL中的行级锁,表级锁,页

第36讲 谈谈MySQL支持的事务隔离级别,以及悲观锁和乐观锁的原理和应用场景

在日常开发中,尤其是业务开发,少不了利用 Java 对数据库进行基本的增删改查等数据操作,这也是 Java 工程师的必备技能之一.做好数据操作,不仅仅需要对 Java 语言相关框架的掌握,更需要对各种数据库自身体系结构的理解.今天这一讲,作为补充 Java 面试考察知识点的完整性,关于数据库的应用和细节还需要在实践中深入学习.今天我要问你的问题是,谈谈 MySQL 支持的事务隔离级别,以及悲观锁和乐观锁的原理和应用场景?典型回答所谓隔离级别(Isolation Level),就是在数据库事务中,

关于MySQL的事务处理及隔离级别

原文地址 :http://blog.sina.com.cn/s/blog_4c197d420101awhc.html 事务是DBMS得执行单位.它由有限得数据库操作序列组成得.但不是任意得数据库操作序列都能成为事务.一般来说,事务是必须满足4个条件(ACID) 原子性(Autmic):事务在执行性,要做到“要么不做,要么全做!”,就是说不允许事务部分得执行.即使因为故障而使事务不能完成,在rollback时也要消除对数据库得影响! 一致性(Consistency):事务操作之后,数据库所处的状态

MySQL事务四个隔离级别

MySQL事务隔离级别详解             MySQL数据结构SQL SQL标准定义了4类隔离级别,包括了一些具体规则,用来限定事务内外的哪些改变是可见的,哪些是不可见的.低级别的隔离级一般支持更高的并发处理,并拥有更低的系统开销. Read Uncommitted (读取未提交的内容)  在该隔离级别,所有事务都可以看到其他未提交事务的执行结果.本隔离级别很少用于实际应用,因为它的性能也不比其他级别好多少.读取未提交的数据,也被称之为脏读(Dirty Read).Read Commit

MySQL数据库事务各隔离级别加锁情况--read committed && MVCC(转)

本文转自https://m.imooc.com/article/details?article_id=17290 感谢作者 上篇记录了我对MySQL 事务 隔离级别read uncommitted的理解.这篇记录我对 MySQL 事务隔离级别 read committed & MVCC 的理解. 前言 可以很负责人的跟大家说,MySQL 中的此隔离级别不单单是通过加锁实现的,实际上还有repeatable read 隔离级别,其实这两个隔离级别效果的实现还需要一个辅助,这个辅助就是MVCC-多版

30秒读懂mysql四种事务隔离级别

一.事务的基本要素(ACID) 1.原子性(Atomicity):事务开始后所有操作,要么全部做完,要么全部不做,不可能停滞在中间环节.事务执行过程中出错,会回滚到事务开始前的状态,所有的操作就像没有发生一样.也就是说事务是一个不可分割的整体,就像化学中学过的原子,是物质构成的基本单位.  2.一致性(Consistency):事务开始前和结束后,数据库的完整性约束没有被破坏 .比如A向B转账,不可能A扣了钱,B却没收到. 3.隔离性(Isolation):同一时间,只允许一个事务请求同一数据,

mysql 4中事务隔离级别

SQL标准定义了4类隔离级别,包括了一些具体规则,用来限定事务内外的哪些改变是可见的,哪些是不可见的.低级别的隔离级一般支持更高的并发处理,并拥有更低的系统开销.Read Uncommitted(读取未提交内容) 在该隔离级别,所有事务都可以看到其他未提交事务的执行结果.本隔离级别很少用于实际应用,因为它的性能也不比其他级别好多少.读取未提交的数据,也被称之为脏读(Dirty Read).Read Committed(读取提交内容) 这是大多数数据库系统的默认隔离级别(但不是MySQL默认的).

浅谈mysql中不同事务隔离级别下数据的显示效果

事务的概念 事 务是一组原子性的SQL查询语句,也可以被看做一个工作单元.如果数据库引擎能够成功地对数据库应用所有的查询语句,它就会执行所有查询,如果任何一条查 询语句因为崩溃或其他原因而无法执行,那么所有的语句就都不会执行.也就是说,事务内的语句要么全部执行,要么一句也不执行. 事务的特性:acid,也称为事务的四个测试(原子性,一致性,隔离性,持久性) automicity:原子性,事务所引起的数据库操作,要么都完成,要么都不执行consisitency:一致性,事务执行前的总和和事务执行后