面试你应该知道的 MySQL 的锁

背景

数据库的锁是在多线程高并发的情况下用来保证数据稳定性和一致性的一种机制。MySQL 根据底层存储引擎的不同，锁的支持粒度和实现机制也不同。MyISAM 只支持表锁，InnoDB 支持行锁和表锁。目前 MySQL 默认的存储引擎是 InnoDB，这里主要介绍 InnoDB 的锁。

使用 InnoDB 的两大优点：一是支持事务；二是支持行锁。

在高并发的情况下事务的并发处理会带来几个问题

由于高并发事务带来这几个问题，所以就产生了事务的隔离级别

举个例子

按照上面 1，2，3，4 的顺序执行会发现第 4 步被阻塞了，必须执行完第 5 步后才能插入成功。这里我们会很奇怪明明锁住的是uid=6 的这一行，为什么不能插入 5 呢？原因就是这里采用了 next-key 的算法，锁住的是（3,10）整个区间。感兴趣的可以试一下。

今天给大家分享了一下 MySQL 的 InnoDB 的事务以及锁的一些知识，通过自己的实际上手实践对这块更加熟悉了，希望大家在看的时候也可以动手试试，这样更能体会，理解的更深刻。

在一个update和insert *** 作频繁的表中 少量数据测试的时候运行良好 在实际运营中 因数据量比较大( 万条记录) 会出现死锁现象 用show processlist查看 可以看到一个update语句状态是Locked 一个delete语句状态是Sending data 查看了一下参考手册 把锁定相关的资料整理下来 以便自己记录和追踪该问题的解决情况

MySQL 支持对MyISAM和MEMORY表进行表级锁定 对BDB表进行页级锁定 对InnoDB 表进行行级锁定 在许多情况下 可以根据培训猜测应用程序使用哪类锁定类型最好 但一般很难说出某个给出的锁类型就比另一个好 一切取决于应用程序 应用程序的不同部分可能需要不同的锁类型 为了确定是否想要使用行级锁定的存储引擎 应看看应用程序做什么并且混合使用什么样的选择和更新语句 例如 大多数Web应用程序执行许多选择 而很少进行删除 只对关键字的值进行更新 并且只插入少量具体的表 基本MySQL MyISAM设置已经调节得很好

在MySQL中对于使用表级锁定的存储引擎 表锁定时不会死锁的 这通过总是在一个查询开始时立即请求所有必要的锁定并且总是以同样的顺序锁定表来管理

对WRITE MySQL使用的表锁定方法原理如下

◆ 如果在表上没有锁 在它上面放一个写锁

◆否则 把锁定请求放在写锁定队列中

对READ MySQL使用的锁定方法原理如下

◆如果在表上没有写锁定 把一个读锁定放在它上面

◆否则 把锁请求放在读锁定队列中

当一个锁定被释放时 锁定可被写锁定队列中的线程得到 然后是读锁定队列中的线程

这意味着 如果你在一个表上有许多更新 SELECT语句将等待直到没有更多的更新

如果INSERT 语句不冲突 可以自由为MyISAM 表混合并行的INSERT 和SELECT 语句而不需要锁定

InnoDB 使用行锁定 BDB 使用页锁定 对于这两种存储引擎 都可能存在死锁 这是因为 在SQL语句处理期间 InnoDB 自动获得行锁定 BDB 获得页锁定 而不是在事务启动时获得

行级锁定的优点

· 当在许多线程中访问不同的行时只存在少量锁定冲突

· 回滚时只有少量的更改

· 可以长时间锁定单一的行

行级锁定的缺点

· 比页级或表级锁定占用更多的内存

· 当在表的大部分中使用时 比页级或表级锁定速度慢 因为你必须获取更多的锁

· 如果你在大部分数据上经常进行 GROUP BY *** 作或者必须经常扫描整个表 比其它锁定明显慢很多

· 用高级别锁定 通过支持不同的类型锁定 你也可以很容易地调节应用程序 因为其锁成本小于行级锁定

在以下情况下 表锁定优先于页级或行级锁定

· 表的大部分语句用于读取

· 对严格的关键字进行读取和更新 你可以更新或删除可以用单一的读取的关键字来提取的一行

&# UPDATE tbl_name SET column = value WHERE unique_key_col = key_value

&# DELETE FROM tbl_name WHERE unique_key_col = key_value

· SELECT 结合并行的INSERT 语句 并且只有很少的UPDATE或 DELETE 语句

· 在整个表上有许多扫描或 GROUP BY *** 作 没有任何写 *** 作

lishixinzhi/Article/program/MySQL/201311/29594

---