自增锁

自增锁,在提交前释放,并发插入高

s,x等锁,在COMMIT扣释放,并发插入需要等待

不能回滚到前面的值

insert -like:

        simple-insert:插入前就能确定插入行数语句

        bulk insert :插入前不确定插入行数的语句 replace ... select

        mixed-mode inserts:insert into t1(c1,c2) values(1,"a"),(null,"b"),(4,"c"),(null,"d")

                                            insert ...  on duplicate key update:自身扩展  (任何KEY 重复,就执行 )

innodb_autoinc_lock_mode:

0:传统方式 ,

simple insert:传统方式

bulk insert :传统方式

对于 INSERT ... SELECT ...   些时其他事务不能插,分配的ID是连续得 ,其他事务不能插入

SQL执行完才释放自增锁

1.

simple insert 并发

bulk insert   传统方式

2.

所有自增都以并发方式

同一SQL语句自增可能不连接

row-based binlog

工作模式1:

工作原理:

BULK INSERT:

ACQUIRE AI

INSERT ..SELECT :如果执行时间长,自增锁持有时间就长,不确定插入的记录数,只能等插入完 才自增,其他事务等待插入

AI=AI+N

RELEASE AI

SIMPLE INSERT : 无SQL 语句执行等待

ACQURE AI

AI=AI+N

RELESE AI

工作模式为 2时的工作原理:

FOR I=AI;I++;   //对BULK INSERT  也能并发插入,对单线插入变差,无益,对多线程插入是益的,自增值可能不连续的

{

ACQUIRE AI LOCK

INSERT ONE REC

AI=Ai+1

RELEAS AI LOCK

}

自增列的创建:

对于联合索引,自增列必须放在第一个列

create table jjj ( a int auto_increment,b int ,key( a,b));      // KEY(b,a)

自增锁:

AUTO_INCREMENT PK 不能持久化,速度快

当重起MYSQL 服务器重新计算值:

SELECT  MAX(AUTO_INC_COL) FROM XX 基于索引查找,而不是全表扫

自增锁相关参数:

  auto_increment_increment:步长值

  auto_increment_offset:初始值

每个节点产生全局唯一自增值设置

auto_increment_offset =1                          auto_increment_offset=2

auto_increment_increment=10                     auto_increment_increment=10

时间: 2024-08-04 03:45:55

自增锁的相关文章

自增锁引发的悲剧

背景 先描述下故障吧 step0: 环境介绍 1. MySQL5.6.27 2. InnoDB 3. Centos 基本介绍完毕,应该跟大部分公司的实例一样 CREATETABLE`new_table`( `id` int(11) NOT NULL AUTO_INCREMENT, `x` varchar(200) DEFAULT '', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=5908151 DEFAULT CHARSET=utf8 C

MySQL AutoIncrement--自增锁模式

自增锁模式 在MYSQL 5.1.22版本前,自增列使用AUTO_INC Locking方式来实现,即采用一种特殊的表锁机制来保证并发插入下自增操作依然是串行操作,为提高插入效率,该锁会在插入语句完成后立即释放,而不是插入语句所在事务提交时释放.该设计并发性能太差,尤其在大批量数据在一条语句中插入时(INSERT SELECT ), 会导致该语句长时间持有这个“表锁”,从而阻塞其他事务的插入操作. 在MYSQL 5.1.22版本开始,InnoDB存储引使用一种轻量级互斥锁(Mutex)来控制自增

自增锁预分配ID

http://www.cnblogs.com/xpchild/p/3825309.html mysql> show create table pp; CREATE TABLE `pp` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=gbk mysql> insert into pp(name)

自增锁ID复用问题

mysql> select * from pp; +----+------+ | id | name | +----+------+ | 1 | xx | | 2 | xx | | 3 | xx | | 4 | xx | | 5 | xx | | 6 | xx | | 7 | xx | | 8 | xx | | 9 | xx | | 10 | xx | | 13 | xx | | 14 | xx | | 15 | xx | | 16 | xx | | 17 | xx | | 18 | xx |

MySQL锁小结

锁的作用:避免并发请求时对同一个数据对象同时修改,导致数据不一致. 怎么加锁: 1.事务T1在对某个数据对象R1操作之前,先向系统发出请求,对其加锁L1. 2.之后,事务T1对该数据对象R1有了相应的控制,在T1释放L1之前,其它事务不能修改R1. 锁类型: 1.排它锁(X). 2.共享锁(S). 通常的锁范围: 1.全局锁(global lock). 2.表锁(table lock). 3.行锁(row lock). InnoDB行锁范围(粒度): 1.record lock. 2.gap l

Innodb 锁系列2 事务锁

上一篇介绍了Innodb的同步机制锁:Innodb锁系列1 这一篇介绍一下Innodb的事务锁,只所以称为事务锁,是因为Innodb为实现事务的ACID特性,而添加的表锁或者行级锁. 这一部分分两篇来介绍,先来介绍下事务锁相关的数据结构 事务锁数据结构 1. 锁模式 /* Basic lock modes */ enum lock_mode { LOCK_IS = 0, /* intention shared */ LOCK_IX, /* intention exclusive */ LOCK_

从一个死锁看mysql innodb的锁机制

背景及现象 线上生产环境在某些时候经常性的出现数据库操作死锁,导致业务人员无法进行操作.经过DBA的分析,是某一张表的insert操 作和delete操作发生了死锁.简单介绍下数据库的情况(因为涉及到真实数据,这里做了模拟,不影响具体的分析和分析的结果.)假设存在如下2张表: Order 表的数据如下: Customer表的数据如下: Order和Customer 在实体关系上存在一个关联,即order实体拥有一个指向customer实体的指针.在数据库设计的时 候,order表的custome

MySQL分表自增ID解决方案(转)

当我们对MySQL进行分表操作后,将不能依赖MySQL的自动增量来产生唯一ID了,因为数据已经分散到多个表中. 应尽量避免使用自增IP来做为主键,为数据库分表操作带来极大的不便. 在postgreSQL.oracle.db2数据库中有一个特殊的特性---sequence. 任何时候数据库可以根据当前表中的记录数大小和步长来获取到该表下一条记录数.然而,MySQL是没有这种序列对象的. 可以通过下面的方法来实现sequence特性产生唯一ID: 1. 通过MySQL表生成ID 在<关于MySQL分

mysql insert锁机制【转】

最近再找一些MySQL锁表原因,整理出来一部分sql语句会锁表的,方便查阅,整理的不是很全,都是工作中碰到的,会持续更新 笔者能力有限,如果有不正确的,或者不到位的地方,还请大家指出来,方便你我,方便大家. 此测试环境 Mysql 5.5 基于innodb 引擎 [sql] view plain copy insert into  table1 values select  … from table2 …. 此种方法,会锁table2 [sql] view plain copy delete t