MySQL基本架构与锁的知识点有哪些

MySql架构

• SQL Layer

• Connection Pool : 连接池，用于接收连接请求和管理连接。

• ManagementService&Utilities 管理服务组件和工具组件，主要提供了一些备份，安全，主从，集群，等功能。

• SQL Interface：主要提供了SQL语句接口。包括SQL解析器，优化器，缓存等。将我们输入的SQL语句，解析成节点树，然后传递给存储引擎执行。

• Storage Engine Layer：可插拔式的存储引擎。常用的有InnoDB，MyISAM等

• File System : 底层文件系统。保存数据，索引，日志等文件。

MySQL锁

锁的分类

按粒度分

• 全局锁（锁database，由SQL Layer层实现）

• 表级锁（由SQL Layer层实现）

• 表数据锁

• 元数据锁

• 行级锁（由存储引擎实现，如InnoDB）:

  可以锁行，也可以锁行与行之间的间隙

按功能分

• 共享锁（S锁）（读锁）

• 排他锁（X锁）（写锁）

锁的演示

表锁

• 表数据锁

-- 对product表加读锁
-- 其他进程仍然可以对product表进行读取，但不能写(包括加读锁本身这个进程，也无法写)
lock table product read;
-- 加锁后，该进程只能访问product表,无法访问其他表。
select * from seller;
ERROR 1100 (HY000): Table 'seller' was not locked with LOCK TABLES
-- 当然可以让当前进程给seller表加锁
lock table seller read;
-- 如此以来，便可以访问seller表，但由于一个进程只能持有一个表锁，故原先的product表锁被释放，product表无法访问


-- 其他未持有锁的session可以访问任意表

-- 释放锁
unlock tables;
-- 或者
unlock table; 
-- 上面两句效果一样
-- 只会释放当前连接进程所持有的表锁，而不是释放所有锁，

-- 对product表加写锁
lock table product write;
-- 其他线程对product表既不能读，也不能写


-- 查看表锁状态
show open tables;

-- 注意，一个连接进程，最多只能持有1个表锁

• 元数据锁（Meta Data Lock）

MDL无需显式使用，在访问一个表时，会自动加元数据锁。MDL的作用是为了保证读写的正确性。

MDL读锁：在对某个表进行增删改查操作时，加MDL读锁。

MDL写锁：在对某个表的结构进行修改(DDL)时，加MDL写锁。

读锁之间不互斥，读写，写写之间互斥。这样是为了保证对表结构操作的安全性。

MDL可以认为是表结构锁。需要改表结构时，自动加MDL写锁，其他时候加MDL读锁

DML,DQL语句，会自动加MDL的读锁

DDL语句，会自动加MDL的写锁

-- 线程A
begin;
select * from product;
-- 在一个事务内，MDL锁是一直被持有的

-- 此时另起一个，线程B
alter table product add type varchar(10);
-- 执行上面的sql，会发现被阻塞住，因为线程B这一句需要MDL写锁

-- 再回到线程A
commit;
-- 线程A提交事务后，释放MDL读锁
-- 此时能看到线程B的sql执行成功

注意：如上图所示，session A 和 session B可以正常执行，session C 就被阻塞了，因为session C需要申请MDL写锁，关键是，session D也会被阻塞。当session A 提交后，会先执行session D，最后再执行session C。

观察发现，如果先开启事务，在事务里执行DDL，先不提交当前事务。再另起一个线程，执行DML，发现DML不会被阻塞。

这是因为DDL在执行完成后，会自动立刻commit（自动commit后会释放MDL写锁）。

申请MDL锁的操作会形成一个队列，队列中写锁获取优先级高于读锁。一旦出现写锁等待，不但当前操作会被阻塞，同时还会阻塞后续该表的所有操作。事务一旦申请到MDL锁后，直到事务执行完才会将锁释放。（这里有种特殊情况如果事务中包含DDL操作，mysql会在DDL操作语句执行前，隐式提交commit，以保证该DDL语句操作作为一个单独的事务存在，同时也保证元数据排他锁的释放。

行锁

行锁是由存储引擎实现的。InnoDB支持行锁和事务，MyISAM不支持行锁和事务。

InnoDB的行锁是通过给索引项加锁实现的。所以，若不是通过索引条件检索的数据，InnoDB会使用表锁。

InnoDB的行锁

按照锁定范围分3种：

• Record Lock：记录锁，锁定索引中的一条记录

• Gap Lock：间隙锁，锁定记录间的间隙

• Next-Key Locks：记录锁+间隙锁组合

按功能分为

• 共享读锁

• 排他写锁

DML语句（INSERT/UPDATE/DELETE）会自动加上排他锁

对于普通SELECT语句，InnoDB不加锁（是通过MVCC的一致性非锁定读的方式完成的，这个后序再做总结），可以通过以下方式，手动添加锁

-- 共享读锁
SELECT * FROM product LOCK IN SHARE MODE;

-- 排他写锁
SELECT * FROM product FOR UPDATE;

-- 查看行锁情况
show status like '%innodb_row_lock%';

意向锁

是InnoDB实现的表级锁，在内部使用，无需用户干预。

MySQL有多粒度的锁实现，即行锁和表锁。那么意向锁存在的意义是为了协调行锁和表锁。试想事务A申请了某表某一行的写锁X，事务B申请了该表的写锁X，那么事务B按理说也能修改事务A锁定的某一行，这就产生了冲突。如果没有意向锁，某事务申请表锁时，可能就得一行一行的扫描，看看是不是所有行都没有锁，所有行都没锁时，才能成功加表锁。这样效率就会很低。

所以意向锁的作用就是表明某个事务有加行锁的意图，即，有人锁住了某一行，或者将要锁住某一行，这样在其他人在加表锁时，就能直接根据意向锁的情况，判断是否能够加表锁，而不必一行一行扫描了。

意向共享锁 （IS）：加行共享锁前，必须先取得IS锁

意向排他锁（IX）：加行排他锁前，必须先取得IX锁

意向锁的作用主要是为了在针对全表操作时获得性能提升。

比如：事务A对某一行加了锁（无论是读锁还是写锁），事务B尝试加表锁，这时如果没有意向锁，就需要遍历检测每一行是否持有行锁，这样性能是极低的。

意向锁只和表锁互斥。

对于上表，可以做如下理解：

若某个表存在IS锁，说明有个事务对某一行加了读锁，此时若要对该表加表锁，只能加S锁，不能加X锁。所以IS和S兼容，和X互斥。

若某个表存在IX锁，说明有个事务对某一行加了写锁，此时若要对该表加表锁，都会被阻塞，S锁和X锁都不能加。所以IX和S和X都互斥。

IX和IX可以共存，可以理解为，有2个事务分别对不同的行加了写锁。