锁与索引
在MySQL的InnoDB引擎里,锁是借助索引来实现的。加锁锁住的其实是索引,也就是叶子节点。
一个表有很多索引,锁的是哪个索引呢?其实就是查询最终使用的那个索引。万一查询没有使用任何索引呢?那么锁住的就是整个表,也就是此时退化为表锁。
如果查询条件的值并不存在,例如:SELECT * FROM your_tab WHERE id = 15 FOR UPDATEid = 15 的值根本不存在,那么怎么锁?InnoDB 引擎会利用最接近 15 的相邻的两个节点,构造一个临键锁。
此时如果别的事务想要插入一个 id=15 的记录,就不会成功。那么范围查询呢?也是利用索引上的数据,构造一个恰好能够装下这个范围的临键锁。例如:SELECT * FROM your_tab WHERE id > 33 FOR UPDATEInnoDB 引擎会构造一个 (33,supremum] 的临键锁,锁住整个范围。supremum 你可以直观理解为 MySQL 认为的一个虚拟的最大值。
因此,我们得出了一个结论:锁和索引密切相关。释放锁时机大部分人在学习锁的时候有一个误区,就是认为锁是在语句执行完毕之后就立刻释放掉的。其实并不是,它是在整个事务结束之后才释放的。换句话来说,当一个事务内部给数据加上锁之后,只有在执行 Rollback 或者 Commit 的时候,锁才会被释放掉。
乐观锁与悲观锁乐观锁和悲观锁实际上是一种逻辑概念,它们是并发控制中常用的两种锁机制。乐观锁是直到要修改数据的时候,才检测数据是否已经被别人修改过。悲观锁是在初始时刻就直接加锁保护好临界资源。乐观锁在数据库中通常指利用 CAS 的思路进行的更新操作。一般的使用形态就是下面这样的。SELECT * FROM your_tab WHERE id = 1; // 在这里拿到了 a = 1// 一大堆的业务操作UPDATE your_tab SET a = 3, b = 4 WHERE id = 1 AND a =1在上面的这个语句里面,预期数据库中 a 的值为 1 才会进行更新。如果此时数据库中的值已经被修改了,那么这个 UPDATE 语句就会失败。业务方通过检测受影响的行数是否为 0,来判断更新是否成功。
悲观锁是指在写入数据时直接加锁。还拿上面这个例子来说吧,就是从最开始的 SELECT 语句就直接加上了锁。SELECT * FROM your_tab WHERE id = 1 FOR UPDATE; // 在这里拿到了 a = 1// 一大堆的业务操作UPDATE your_tab SET a = 3, b = 4 WHERE id = 1在加上锁之后,就可以直接更新了。这个时候不需要担心别人可以在 SELECT 和 UPDATE 之间将 a 更新为别的值。在使用乐观锁和悲观锁时,需要考虑数据一致性和并发性的问题。乐观锁适用于读多写少的场景,互联网中大部分应用都属于这一类。而悲观锁则适用于写多读少的场景,比如在金融领域里面对金额的操作就是以写为主。相比之下,乐观锁的性能要比悲观锁好很多。不过因为乐观锁的代码写起来比较复杂,所以很多人偷懒就会直接使用悲观锁。行锁与表锁行锁与表锁都是根据锁的范围来划分的。一般来说,行锁是指锁住行,可能是锁住一行,也可能是锁住多行。表锁则是直接将整个表都锁住。那么在 MySQL 里面,InnoDB 引擎同时支持行锁和表锁。但是行锁是借助索引来实现的,也就是说,如果你的查询没有命中任何的索引,那么 InnoDB 引擎是用不了行锁的,只能使用表锁。当然,如果用的是 MySQL,类似于 MyISAM 引擎,那么只能使用表锁,因为这些引擎不支持行锁。共享锁与排它锁共享锁和排它锁是在互斥的角度上看待锁的。共享锁是指一个线程加锁之后,其他线程还是可以继续加同类型的锁。排它锁是指一个线程加锁之后,其他线程就不能再加锁了。