mysql并发控制原理知识点

mysql是主流的开源关系型数据库，提供高性能的数据存储服务。在做后端开发时，有时会遇到性能瓶颈，这些瓶颈有时并不是来自应用本身，而是来自数据库层面。

所以所以掌握mysql的一些底层原理有助于我们更好地理解mysql，对mysql进行性能调优，

从而开发高性能的后端服务。

1、mysql的逻辑框架

mysql逻辑框架图如下：

最上层是处理客户端过来的连接的。

主要做连接处理、授权认证、安全等。mysql在这一层维护了一个线程池，用于处理来自客户端的连接。mysql可以使用用户名密码认证，

也可以使用ssl基于x.509证书认证。

第二层由三部分组成：查询缓存、解析器、优化器。解析器用来解析sql语句，优化器会对解析之后的语句进行优化。

在解析查询前，服务器会先检查查询缓存，如果能在其中找到对应的查询结果，则无需再进行查询解析、优化等过程，直接返回查询结果。存储过程、触发器、视图等都在这一层实现。

第三层是存储引擎，存储引擎负责在mysql中存储数据、提取数据、开启一个事务等等。存储引擎通过api与上层进行通信，这些api屏蔽了不同存储引擎之间的差异，使得这些差异对上层查询过程透明。存储引擎不会去解析sql。mysql最常用的存储引擎是innodb。

2、mysql的并发控制

如果多个线程同时操作数据，就有可能引发并发控制的问题。

2-1、读写锁

如果多个线程都只是读数据，其实可以一起读，不会互相影响，这个时候应该使用“读锁”，也称为共享锁。

获取读锁的线程之间互相不会阻塞，可以同时读取一个资源。

如果有一个线程需要写数据，则应该使用“写锁”，也成为排它锁。

写锁会阻塞其它的写锁和读锁，直至写操作完成。

2-2、锁粒度

首先明确一个概念：在给定的资源上，需要加锁的数据越少，系统能够承载的并发量就越高。

但加锁也是需要消耗资源的，如果系统花费大量的时间来管理锁，而不是存取数据，

那么系统的性能可能会因此受影响。

所以一个好的“锁策略”就是要在锁的开销和数据的安全性之间寻求平衡，mysql支持多个存储引擎的架构，

每种存储引擎都可以实现自己的锁策略和锁粒度。

2-3、表锁和行锁

表锁顾名思义就是锁住整张表。表锁开销比较小。对表加写锁后，其它用户对这张表的所有读写操作都会被阻塞。

在mysql中，尽管存储引擎可以提供自己的锁，但mysql有时候也会使用表锁，比如alter table之类的语句。

写锁比读锁有更高的优先级，因此一个写锁请求可能会插入到读锁队列的前面。

行级锁即锁住整行，可以最大程度地支持并发处理，但加解锁的开销也会比较大。行级锁只在储存引擎层实现，

所有的存储引擎都以自己的方式实现了行级锁。

3、mvcc

mvcc即“多版本并发控制”，可以认为mvcc是行级锁的一个变种，但是它在很多情况下避免了加锁操作，

因此开销更低。

主流的关系型数据库都实现了mvcc，但实现机制各有不同。实际上mvcc也没有一个统一的标准。

但大都实现了非阻塞的读操作，写操作也只是锁定必要的行。

mvcc保证的是每个事务里面在执行期间看到的数据都是一致的。

但不同的事务由于开始的时间不同，所以可能对同一张表，同一时刻看到的数据是不一样的。

在mysql的innodb引擎，是通过给每行记录后面保存两个隐藏的列来实现的。

一个是保存行的创建时间，另一个保存了行的过期时间（或删除时间）。

实际上存储的并不是实际的一个时间戳，而是‘系统版本号'。

每次开启一个事务，系统版本号都会递增。事务开始时，系统版本号会作为事务的版本号，用来和查询到的行的版本号进行比较。

下面分别介绍常见的crud操作中版本号是怎么工作的：

insert

保存当前系统版本好的作为行版本号

delete

保存当前的系统版本号到这行数据的“删除版本”。

update

插入一行新纪录，保存当前系统版本号作为航版本号，同时保存当前系统版本号到原来的行的“删除版本”。

select

只查找版本早于当前事务版本的行。这样可以保证事务读取的行，要么之前就存在，

要么是这个事务本身自己插入或者修改的。

行的“删除版本”要么未定义，要么大于当前事务版本号。这样可以确保事务读取到的行，

在事务之前没有被删除。

mvcc只在repeatable read和read committed两个隔离级别下工作，其它两个隔离级别不能工作。

因为read uncommitted总是读取最新的数据防，而不是符合当前事务版本的数据行。而serializable则会对所有读取的行都加锁。

以上就是mysql的并发控制原理的详细内容，如果大家有任何补充可以联系小编。