锁与索引
在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 引擎，那么只能使用表锁，因为这些引擎不支持行锁。共享锁与排它锁共享锁和排它锁是在互斥的角度上看待锁的。共享锁是指一个线程加锁之后，其他线程还是可以继续加同类型的锁。排它锁是指一个线程加锁之后，其他线程就不能再加锁了。
