多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
[TOC] ### 什么是锁 锁是数据库系统区别于文件系统的关键特性。锁机制用于管理对共享资源的并发访问。 ### lock 与 latch latch 一般称为闩锁(轻量级的锁),因为其要求锁定的世界必须非常短。若持续的时间长,则应用性能会非常差。分为mutex(互斥量)和rwlock(读写锁)。其目的是用来保证并发线程操作临界资源的正确性,并且通常没有死锁检测的机制。 lock 的对象是事务,用来锁定的是数据库中的对象,如表、页、行。并且一般的对象尽在事务commit 或者rollback后释放。有死锁机制的。 ![](https://box.kancloud.cn/a92a45086753d108ea39aaf95f460ec4_861x252.png) 对于latch 可以通过`show engine innodb mutex`来进行查看 ![](https://box.kancloud.cn/cb124a840e45134238fe1f53ebd6b489_351x64.png) ![](https://box.kancloud.cn/ee12417c9aa47fad0f45412b96a53334_853x317.png) ### Innodb 存储引擎中的锁 (1)共享锁(s),允许事务读一行数据。 (2)排它锁(x)事务删除或者更新一行数据。 ![](https://box.kancloud.cn/f3b9345c747dcb223afc3da59be44dfc_873x136.png) 意向锁是将锁定的对象分为多个层次,意向锁意味着事务希望在更细粒度(fine granularity)上进行加锁。 在innodb 1.0版本之前,用户只能通过命令show full processlist,show engine innodb status等来查看当前数据库中锁的请求,然后在判断事务锁的情况。 1.0版本之后 在INFORMATION_SCHEMA 架构下添加了表INNODB_TRX、INNODB_LOCK、INNODB_LOCK_WAITS。这三张表分析锁问题。 ![](https://box.kancloud.cn/dd196cc197b6b788760452bfa3b56f7e_913x345.png) 如上图可以通过下面的命令,获取锁的信息: `select * from information_schema.innodb_trx\G;` ![](https://box.kancloud.cn/5287a85230becab04b066748c0096e37_840x337.png) 输入`select * from information_schema.innodb_locks`; 可以获取如上图的相关信息 InnoDB存储引擎对于select语句支持两种一致性的锁定读(locking read)操作: (1)`select ... for update`(排它锁 X)其他事务不能对已锁定的行加上任何锁。 (2)`select ... lock in share mode`(共享锁) 其他事务可以向被锁定的行加s锁,但是如果加x锁就会别阻塞。 #### 自增长及锁 mysql5.1.22版本开始 innodb存储引擎提供了`innodb_autoinc_lock_mode`来控制自增长的模式 默认值为1。 ![](https://box.kancloud.cn/b37a17d383a7f595ee94e0bec1734f76_857x544.png) innodb:必须是索引的第一列 myisam不需要。 #### 外键和锁 innodb 使用外键如果没有加索引 搜索引擎会自动将其添加索引。因为这样就可以避免表锁。 ### 锁的算法 #### 行锁的3中算法 (1)Record Lock:单行记录上的锁 锁住的是索引记录 如果没有任何一个索引 那么使用隐式的主键来进行锁定。 (2)Gap Lock:间隙锁,锁定一个范围,但不包含记录本身 (3)Next-key Lock : Gap Lock + Record Lock,锁定一个范围,并锁定记录本身。 ![](https://box.kancloud.cn/eceb720d133454f45e6d469da2f24175_866x264.png) ~~~~ create table z (a int,b int ,primary key(a),key(b)); insert into z select 1,1; insert into z select 3,1; insert into z select 5,3; insert into z select 7,6; insert into z select 10,8; select * from z where b=3 for update; ~~~~ 很明显,这时sql语句通过索引列b进行查询, 会使用传统的Next-key Lock 技术加锁,并且由于两个索引,其需要分别进行锁定。对于聚集索引,其仅对列a等于5的索引加上Record Lock。 而对于辅助索引,其加上的是Next-Key Lock,锁定的范围是(1,3),特别需要注意的是,InnoDB存储引擎还会对辅助索引下一个键位加上gap lock,即还有一个辅助索引范围为(3,6)的锁,因此,若在新会话B中运行下面的sql语句执行会被堵塞: `select * from z where a= 5 lock in share mode;`(第一条) `insert into z select 4,2;`(第二条) `insert into z select 6,5;`(第三条) 第一条语句不会被执行,因为会话A中执行的sql语句已经吧聚集索引列a=5的值加上X锁,因此执行会阻塞。 第二天语句主键插入没有4,没有问题,但是插入辅助索引值2在锁定的范围(1,3)中,因此执行同样会被阻塞。第三个sql语句,插入的主键没有被锁定,5也不在(1,3)之间。但插入的值5在另一个锁定的范围(3,6)中,故同样需要等待。 下面的sql语句不会被阻塞,可以立即执行: `insert into z select 8,6;` `insert into z select 2,0;` `insert into z select 6,7;` 若此时没有Gap Lock 锁定(3,6),那么用户可以插入索引b列为3的记录,这会导致会话A中的用户再次执行插叙时会返回不同的记录,即导致 phantom problem(幻读)问题的产生。 可以通过一些的方式显式地关闭Gap Lock; (1)将事务的隔离级别设置为READ COMMITTED (2)将参数innodb_locks_unsafe_for_binlog设置为1 在上述的配置下,除了外键约束和唯一性检查依然需要的Gap Lock,其余情况仅使用Record Lock进行锁定。 上述设置破坏了事务的隔离性,并且对于replication(复制),可能会导致主从数据的不一致。 而且从性能上来看 read committed 不会优于事务隔离级别read repeatable。 对于inset的操作, 如果被锁定则不允许查询。 会话A中表示已经锁定了 所以其他会话插入同样会导致阻塞。 #### 解决 phantom problem(幻读)