数据库常用锁

在数据库管理系统中，锁是用于管理并发访问的一种机制，以确保数据的一致性和完整性。常见的数据库锁包括：

1.共享锁（Shared Lock）： 又称读锁，允许一个事务去读取一行，阻止其他事务获得相同数据集的排它锁，若事务T对数据对象A加上S锁，则事务T可以读A，但不能修改A，其他事务只能对再对A加S锁，而不能加X锁，直到T释放A上的锁，这保证了其他事务可以读A，但在释放A上的S锁之前不能对A做任何修改多个事务可以同时持有共享锁，用于读取数据而不修改。共享锁之间不会互相冲突，因此可以提高并发性。
2.排他锁（Exclusive Lock）： 又称写锁，允许获取排它锁的事物更新数据，阻止其他事务取得相同的数据集共享读锁和排它写锁，若事务T对数据对象A加上X锁，事物T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T 释放A上的锁,一次只有一个事务可以持有排他锁，用于写入或修改数据。其他事务无法同时持有相同数据的排他锁，以确保在修改时数据的一致性。
3.行级锁（Row-level Lock）： InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点，MySQL于Oracle不同，后者是通过在数据块中对相应的数据行加锁来实现的，InnoDB只有通过索引条件检索数据，InnoDB才使用行级锁
行锁的劣势：开销大；加锁慢；会出现死锁
行锁的优势：锁的粒度小，发生锁冲突的概率低；处理并发的能力强
4.表级锁（Table-level Lock）： InnoDB在使用过程中只要不通过索引检索数据时，全部是表锁。
开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低
MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行更新操作（UPDATE、DELETE、INSERT等）前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁。
5.意向锁（Intent Lock）： 事物B对一行数据使用行锁，当有另一个事物A对这个表使用了表锁，那么这个行锁就会升级为表锁，事务A在申请行锁（写锁）之前，数据库会自动先给事务A申请表的意向排他锁。当事务B去申请表的写锁时就会失败，因为表上有意向排他锁之后事务B申请表的写锁时会被阻塞。
当一个事务在需要获取资源的锁定时，如果该资源已经被排他锁占用，则数据库会自动给该事务申请一个该表的意向锁。如果自己需要一个共享锁定，就申请一个意向共享锁。如果需要的是某行（或者某些行）的排他锁定，则申请一个意向排他锁。
6.自旋锁（Spin Lock）： 在多处理器系统中使用的锁，它避免了进程进入休眠状态，而是反复检查锁是否可用。如果锁不可用，线程会一直尝试获取锁。
7.数据库引擎特定的锁： 不同的数据库管理系统可能还提供了一些特定的锁机制，如MySQL的Record Locks和Next-Key Locks。
8.共享意向排他锁（Shared Intent Exclusive Lock）： 又称写锁，允许获取排它锁的事物更新数据，阻止其他事务取得相同的数据集共享读锁和排它写锁，若事务T对数据对象A加上X锁，事物T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T 释放A上的锁,表示事务打算获取共享锁，但最终可能升级为排他锁。

9.乐观锁（Optimistic Lock）
乐观锁的特点先进行业务操作，不到万不得已不去拿锁。即“乐观”的认为拿锁多半是会成功的，因此在进行完业务操作需要实际更新数据的最后一步再去拿一下锁就好。
乐观锁是否在事务中其实都是无所谓的，其底层机制是这样：在数据库内部update同一行的时候是不允许并发的，即数据库每次执行一条update语句时会获取被update行的写锁，直到这一行被成功更新后才释放。因此在业务操作进行前获取需要锁的数据的当前版本号，然后实际更新数据时再次对比版本号确认与之前获取的相同，并更新版本号，即可确认这之间没有发生并发的修改。如果更新失败即可认为老版本的数据已经被并发修改掉而不存在了，此时认为获取锁失败，需要回滚整个业务操作并可根据需要重试整个过程。

10.悲观锁（Pessimistic Lock）
悲观锁的特点是先获取锁，再进行业务操作，即“悲观”的认为获取锁是非常有可能失败的，因此要先确保获取锁成功再进行业务操作。通常所说的“一锁二查三更新”即指的是使用悲观锁。通常来讲在数据库上的悲观锁需要数据库本身提供支持，即通过常用的select … for update操作来实现悲观锁。当数据库执行select for update时会获取被select中的数据行的行锁，因此其他并发执行的select for update如果试图选中同一行则会发生排斥（需要等待行锁被释放），因此达到锁的效果。select for update获取的行锁会在当前事务结束时自动释放，因此必须在事务中使用。
这里需要注意的一点是不同的数据库对select for update的实现和支持都是有所区别的，例如oracle支持select for update no wait，表示如果拿不到锁立刻报错，而不是等待，mysql就没有no wait这个选项。另外mysql还有个问题是select for update语句执行中所有扫描过的行都会被锁上，这一点很容易造成问题。因此如果在mysql中用悲观锁务必要确定走了索引，而不是全表扫描。

这些锁的使用取决于数据库管理系统和具体的应用场景。合理的锁策略可以提高系统的并发性能，而不当的锁使用可能导致性能下降或死锁等问题。在设计数据库应用时，需要谨慎选择和使用不同类型的锁，并考虑事务的隔离级别以及并发控制的需要。