mysql源码分析 锁_从源码分析 MySQL 死锁问题入门

这篇文章主要讲的是如何经过调试 MySQL 源码，知道一条 SQL 真正会拿哪些锁，再也不抓虾，瞎猜或者何登成大神没写过的场景就不知道如何处理了sql

经过好多个深夜艰难的单步调试，终于找到了一个理想的断点，能够看到大部分获取锁的过程bash

代码在lock0lock.c的static enum db_err lock_rec_lock() 函数中，这个函数会显示，获取锁的过程，以及获取锁成功与否的状况函数

对于以前何登成大神博客里面的内容(hedengcheng.com/?p=771)， 咱们来作实验逐个验证(如下介绍的都是在 RC 隔离级别下的实验)测试

场景1：经过主键进行删除

表结构优化

CREATE TABLE `t1` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` varchar(10) NOT NULL DEFAULT '',

PRIMARY KEY (`id`)

) ENGINE=InnoDB;

delete from t1 where id = 10;

复制代码

能够看到，对索引 PRIMARY 加锁，mode = 1027，1027是什么意思呢？1027 = LOCK_REC_NOT_GAP + LOCK_X(非 gap 的记录锁且是 X 锁)ui

过程以下 spa

结论：根据主键 id 去删除数据，且没有其它索引的状况下，此 SQL 只须要在 id = 10 这条记录上对主键索引加 X 锁便可

场景2：经过惟一索引进行删除

表结构作了微调，增长了 name 的惟一索引3d

构造数据

CREATE TABLE `t2` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` varchar(10) NOT NULL DEFAULT '',

PRIMARY KEY (`id`),

UNIQUE KEY `uk_name` (`name`)

) ;

INSERT INTO `t2` (`id`, `name`) VALUES

(1,'M'),

(2,'Y'),

(3,'S'),

(4,'Q'),

(5,'L');

测试sql语句

delete from t2 where name = "Y"

复制代码

来看实际源码调试的结果 第一步： 调试

第二步：

结论：这个过程是先对惟一键 uk_name 加 X 锁，而后再对聚簇索引(主键索引)加 X 锁

过程以下 code

场景3：经过普通索引进行删除

构造数据

CREATE TABLE `t3` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` varchar(10) NOT NULL DEFAULT '',

PRIMARY KEY (`id`),

KEY `idx_name` (`name`)

);

INSERT INTO `t3` (`id`, `name`) VALUES

(1,'N'),

(2,'G'),

(3,'I'),

(4,'N'),

(5,'X');

测试语句：

delete from t3 where name = "N";

复制代码

调试过程如图：

结论：经过普通索引进行更新时，会对知足条件的全部普通索引加 X 锁，同时会对相关的主键索引加 X 锁

过程以下

场景4：不走索引进行删除

CREATE TABLE `t4` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` varchar(10) NOT NULL DEFAULT '',

PRIMARY KEY (`id`)

)

INSERT INTO `t4` (`id`, `name`) VALUES

(1,'M'),

(2,'Y'),

(3,'S'),

(4,'Q'),

(5,'L');

delete from t4 where name = "S";

复制代码

总共有 5 把 X 锁，剩下的 3 把就不一一放上来了

结论：不走索引进行更新时，sql 会走聚簇索引(主键索引)对全表进行扫描，所以每条记录，不管是否知足条件，都会被加上X锁。还没完... 可是为了效率考量，MySQL作了优化，对于不知足条件的记录，会在判断后放锁，最终持有的，是知足条件的记录上的锁，可是不知足条件的记录上的加锁/放锁动做不会省略。

过程以下