MySQL编程 优化篇（六） 锁问题

目录

MyISQM表锁

InnoDB锁问题

事务隔离级别

InnoDB的行锁模式

InnoDB行锁实现方式

Next-Key锁

恢复和复制的需要，对InnoDB锁机制的影响

什么时候使用表锁

关于死锁

---

具体的可以查看我的另外一篇博客，下面只摘取部分介绍！

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。

行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。

页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

MyISQM表锁

MyISAM表的读操作与写操作之间，以及写操作之间是串行的！

MyISAM在执行查询语句(SELECT) 前，会自动给涉及的所有表加读锁，在执行更新操作(UPDATE、 DELETE、INSERT等)前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此，用户一般不需要直接用LOCKTABLE命令给MyISAM表显式加锁。

一个进程请求某个MyISAM表的读锁，同时另一个进程也请求同一表的写锁，MySQL如何处理呢？答案是写进程先获得锁。不仅如此，即使读请求先到锁等待队列，写请求后到，写锁也会插到读锁请求之前！这是因为MySQL认为写请求一般比读请求要重要。这也是MyISAM不太适合与有大量更新和查询操作应用的原因。

无死锁！

InnoDB锁问题

InnoDB 与 MyISAM 的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁。

事务的ACID属性不予介绍。

并发事务带来的问题：脏读、不可重复读、幻读和更新丢失。

下面主要介绍一下更新丢失。

更新丢失（Lost Update）：当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题——最后的更新覆盖了由其他事务所做的更新。

案例：

两个编辑人员制作了同一文档的电子副本。每个编辑人员独立地更改其副本，然后保存更改后的副本，这样就覆盖了原始文档。最后保存其更改副本的编辑人员覆盖另一个编辑人员所做的更改。如果在一个编辑人员完成并提交事务之前，另一个编辑人员不能访问同一文件，则可避免此问题。

事务隔离级别

数据库实现事务隔离的方式，基本上可分为以下两种。

• 读取数据前，对其加锁，阻止其他事务对数据进行修改。

• 不用加任何锁，通过一定机制生成一个数据请求时间点的一致性数据快照（Snapsho