自增表死锁问题分析及处理

一个死锁信息,涉及到自增表的死锁,测试,压测产生的死锁信息,并发500,信息如下:
1234

从上面死锁信息来看,lock mode AUTO-INC waiting,应该是表的自增列的问题,初步了解,这个死锁和 innodb_autoinc_lock_mode 的值有一定的关系,但也不因全归咎于mysql的问题。

从5.6的用户手册中查找到AUTO-INC的相关信息:

InnoDB uses a special lock called the table-level AUTO-INC lock for inserts into tables with AUTO_INCREMENT columns. This lock is normally held to the end of the statement (not to the end of the transaction), to ensure that auto-increment numbers are assigned in a predictable and repeatable order for a given sequence of INSERT statements

InnoDB在为自增列产生值的时候,使用一种叫做AUTO_INC的表级锁来做控制。这种锁是作用于语句的而不是事务(即语句执行完了锁就会被释放)。使用这种锁是为了确保自增列的值的可预见性和可重复性。可预见性是说当一条insert语句作用于多行时,这些行的自增列基于第一行来说是可预见的;可重复执行是指基于语句的复制在slave重放时自增列的值与master的一致。

innodb_autoinc_lock_mode:

默认值:1,可取值为:0,1,2

在 mysql5.1.22之前,没有这个选项,默认都是0,在并发数大于208以上可能出现很多死锁

下面解释一下innodb_autoinc_lock_mode 几种默认值的含义:

0:traditonal (每次都会产生表锁)

1:consecutive (默认,可预判行数时使用新方式,不可时使用表锁,对于simple insert会获得批量的锁,保证连续插入)

Simple inserts:

直接通过分析语句,获得要插入的数量,然后一次性分配足够的auto_increment id,只会将整个分配的过程锁住。(INSERT, INSERT … VALUES(),VALUES())

Bulk inserts:

因为不能确定插入的数量,因此使用和以前的模式相同的表级锁定。(INSERT … SELECT, REPLACE … SELECT, LOAD DATA)

其中 insert ..... select ..... ,是特殊的select加X锁的情况,原因是为保证数据的一致性(M-S环境)

Mixed-mode inserts:

直接分析语句,获得最坏情况下需要插入的数量,然后一次性分配足够的auto_increment id,只会将整个分配的过程锁住。

(INSERT INTO t1 (c1,c2) VALUES (1,’a'), (NULL,’b'), (5,’c'), (NULL,’d');INSERT … ON DUPLICATE KEY UPDATE)

2:interleaved (不会锁表,来一个处理一个,并发最高)

这种模式是来一个分配一个,而不会锁表,只会锁住分配id的过程,和innodb_autoinc_lock_mode = 1的区别在于,不会预分配多个,这种方式并发性最高。

从上面来看,一般 innodb_autoinc_lock_mode = 1 默认值,基本上满足需要。

虽说 innodb_autoinc_lock_mode = 2 不安全,但是在 binlog_format=ROW,transaction-isolation=READ-COMMITTED , innodb_autoinc_lock_mode = 2 是非常安全的。

至于,针对高并发的表,主键列的设置建议如下:

1.采用DB的自增属性,此时,需要调整DB参数,尽可能提高并发:
binlog_format=ROW,transaction-isolation=READ-COMMITTED , innodb_autoinc_lock_mode = 2

2.采用程序生成全局自增ID,利用redis、memcache集合生成 ,这也是推荐的方式

innodb_autoinc_lock_mode这个参数控制着在向有auto_increment 列的表插入数据时,相关锁的行为;

通过对它的设置可以达到性能与安全(主从的数据一致性)的平衡

【0】我们先对insert做一下分类

  首先insert大致上可以分成三类:
    1、simple insert 如insert into t(name) values('test')
    2、bulk insert 如load data | insert into ... select .... from ....
    3、mixed insert 如insert into t(id,name) values(1,'a'),(null,'b'),(5,'c');

【1】innodb_autoinc_lock_mode 的说明

  innodb_auto_lockmode有三个取值:
    1、0 这个表示tradition 传统
    2、1 这个表示consecutive 连续
    3、2 这个表示interleaved 交错

【1.1】tradition(innodb_autoinc_lock_mode=0) 模式:

  1、它提供了一个向后兼容的能力
  2、在这一模式下,所有的insert语句("insert like") 都要在语句开始的时候得到一个
     表级的auto_inc锁,在语句结束的时候才释放这把锁,注意呀,这里说的是语句级而不是事务级的,
       一个事务可能包涵有一个或多个语句。
  3、它能保证值分配的可预见性,与连续性,可重复性,这个也就保证了insert语句在复制到slave
          的时候还能生成和master那边一样的值(它保证了基于语句复制的安全)。
     4、由于在这种模式下auto_inc锁一直要保持到语句的结束,所以这个就影响到了并发的插入。

【1.2】consecutive(innodb_autoinc_lock_mode=1) 模式:

  1、这一模式下去simple insert 做了优化,由于simple insert一次性插入值的个数可以立马得到
          确定,所以mysql可以一次生成几个连续的值,用于这个insert语句;总的来说这个对复制也是安全的
          (它保证了基于语句复制的安全)
  2、这一模式也是mysql的默认模式,这个模式的好处是auto_inc锁不要一直保持到语句的结束,只要
          语句得到了相应的值后就可以提前释放锁

【1.3】interleaved(innodb_autoinc_lock_mode=2) 模式
  1、由于这个模式下已经没有了auto_inc锁,所以这个模式下的性能是最好的;但是它也有一个问题,就是
          对于同一个语句来说它所得到的auto_incremant值可能不是连续的。

【2】如果你的二进制文件格式是mixed | row 那么这三个值中的任何一个对于你来说都是复制安全的。

  由于现在mysql已经推荐把二进制的格式设置成row,所以在binlog_format不是statement的情况下最

  好是innodb_autoinc_lock_mode=2 这样可能知道更好的性能。

最后以一个关于auto_increment 的例子来结束

例子:不要没事去更新一个auto_increment 列的值

第一步:重现一下场景

复制代码
create table t(x int auto_increment not null primary key);
insert into t(x) values(0),(null),(3);
select * from t;
+---+
| x |
+---+
| 1 |
| 2 |
| 3 |
+---+
复制代码

第二步:重现一下引发问题的SQL

复制代码
update t set x=4 where x=1;
select * from t;
+---+
| x |
+---+
| 2 |
| 3 |
| 4 |
+---+
复制代码

第三步:重现一下总是的表现形式

insert into t(x) values(0);
ERROR 1062 (23000): Duplicate entry '4' for key 'PRIMARY'

第四步:对问题的总结

  执行完第一步的时候mysql知道下一个auto_increment值是4。

  执行完第二步的时候mysql并不知道4已经被人为的占用了,所以执行第三步的时候就出错了。

原文地址:https://www.cnblogs.com/DataArt/p/10174702.html