学习笔记之mysql锁机制

今天翻了一下《高性能mysql》看了几页之后感觉到，之前虽然有很多用过的东西但是一直处于知道这个东西怎么用。不知道为什么会这样。

今天翻了一下本书，前面简单的介绍也让我受益良多。今天给大家分享一下今天看到的锁的介绍。

 

一，表锁

    表锁在你锁定期间，别人事无法进行写的操作。如果你的写锁，那么别人连读的操作也会堵塞。

    表锁的特性锁开销少，但是造成阻塞范围较大。对其他人的操作影响较多。

    

二，行级锁

    行级锁可以最大程度的支持并发，但也很多程度的带来了锁的开销。在InnoDB和XtraDB以及其他一些储存引擎中实现了行级锁。行级锁只在储存引擎层实现，而mysql服务层没有实现。服务层完全不了解储存引擎中锁的实现。

 

三，共享锁（读锁）

    共享锁相互之前不会阻塞，多个客户端同时读取同一资源而互补干扰。

 

四，排它锁（写锁）

    写锁会阻塞其他写锁和读锁，等到写锁取消后才能进行操作。这事处于安全策略考虑。只有这样才能确保在既定的时间内，只有一个用户能执行写的操作。防止其他用户读取正在写入的同一资源。

    写锁的优先级会高于读锁，因此一个写锁请求可能会插到读锁的前面。

 

五，死锁

    死锁不是锁的类型，而是因为加锁造成的数据堵塞或者说bug。在两个或者多个事物在同一资源上相互占用，并求情锁定对方占用的资源。比如说我开启一个事物需要修改A数据两次的同时，另一个人开启了一个事物也在修改A也是两次数据。如果凑巧A数据被同时update的时候同时加锁，那么在第二次执行修改数据的时候双方都在等待对方可以释放锁。这样就陷入了死循环。

    为了解决这个问题数据库系统实现了各种死锁检测和死锁超市的机制。越是负责的系统，比如innoDB储存引擎，越能检测死锁的循环依赖，并立即返回一个错误。目前innodb处理死锁的方法是将持有最少行级排它锁的事务进行回滚。

 

理想的方式是指对会修改的数据进行精确的锁定，在任何时候锁定的数据量越小。执行并发的程序就越高。问题是加锁也需要消耗资源的，包括锁，检查锁是否已经接触，释放锁都会增加系统的开销。如果系统话费大量的时间来管理锁，而不是存储数据，那么系统的性能可能会因此受到影响。

锁策略就是在锁的开销和数据安全之间寻求一个平衡。