Mysql架构与并发控制

[TOC]
来源：《MySQL高性能》

MySQL的架构

mysql的架构呢是遵循了分层的架构。上层是服务器的服务和查询执行引擎，下层是存储引擎。

它的架构可以在多种不同场景中应用并发挥好的作用。它可以嵌入到应用程序中。也可以支持数据仓库、内容索引和部署软件、高可用的冗余系统、在线事物处理系统等各种应用类型。

图一：mysql 逻辑架构图

解释：
第一层的连接/线程处理呢主要是进行的工作是连接处理、授权认证、安全等等。和大多数B/S的架构相同。每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询只会在这个单独的线程中执行，改线程只能轮流在某个CPU核心或者CPU中运行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或者销毁线程。
第二层包含了MySQL的大多数核心服务功能。如：查询解析、分析、缓存以及内置函数、存储过程、触发器、视图等。MySQL会解析查询，并创建内部数据结构（解析树），然后对其进行优化。后期会详细讲解优化细节。对于select语句，在解析查询之前，服务器会先检查查询缓存，如果能够在其中找到对应的查询，服务器就不必再执行查询解析、优化和执行的整个过程，而是直接返回查询缓存的结果集。
第三层主要负责数据的存储和提取（存储引擎）。InnoDB是MySQL默认的事务型引擎，也是最重要的、使用最广泛的。它被设计用来处理大量的短期事务，短期事务大部分情况是正常提交的。很少被回滚。InnoDB的数据存储在表空间中，表空间是由InnoDB管理的一个黑盒子，由一系列的数据文件组成。它采用MVCC来支持高并发，并且实现了四个标准的隔离级别。隔离级别的概念会在下一节给大家介绍。

MySQL的并发控制

多个查询需要在同一时刻修改数据，会产生并发控制问题。
例如：两个进程在同一时刻对同一个邮箱进行投递邮件，会发生什么情况呢？显然，邮箱的数据会被损坏，两封邮件的内容会交叉地附加在邮箱文件的末尾。设计良好的邮箱投递系统会通过锁来防止数据损坏。但这并不支持并发处理。因为人以时刻只有一个进程可以修改邮箱数据。

并发控制这里主要介绍两个概念，一个是读写锁，一个是锁的粒度。

读写锁

若只是单纯的从邮箱中读取数据，则不会产生什么问题，若是在读取的过程中有一个用户试图去删除编号为25的邮件，这时可能读取邮件的用户会报错退出，也可能读到不准确的数据。解决这类问题的方法就是使用读写锁。其中读锁也叫共享锁，写锁叫排它锁。本节呢先不讨论具体的实现方式，只是简单介绍下读写锁的概念。

读锁（共享锁）

读锁又称为共享锁，相互之间不堵塞。多个请求可以在同一个资源目标进行读取，互相不干扰。

写锁（排它锁）

写锁会阻塞其他的写锁和读锁，这样的话可以保证在同一时间里只有同一个用户能执行写入的操作，防止其他用户读取正在写入的同一资源。
在世纪的数据库系统中，每时每刻都在发生锁定，当某个用户在修改某一部分数据时，MySQL会通过锁定防止其他用户读取同一数据。大多数时候，MySQL锁的内部管理都是透明的。

锁粒度

锁粒度让提高共享资源的并发性更有选择性。尽量只锁定需要修改的部分数据。理想的方式就是只会对修改的数据片进行精确的锁定。这里不是说锁定的数量越少，则系统的并发程度越高，只要相互之间不发生冲突即可，还要考虑加锁消耗的资源问题（获得锁、检查锁是否已经解除、释放锁等），因为加锁的同时也会增加系统的开销，如果是花费大量时间来管理锁，而不是存取数据，那么系统的性能可能会因此受到影响。

表锁

表锁是MySQL中最基本的锁策略，并且是开销最小的策略。当一个表要插入、删除、更新记录时，首先需要获得写锁，这会阻塞其他用户对该表的读写操作。只有没有写锁的时候，其他用户才能进行读取的操作。读锁之间是不进行相互阻塞的。（写锁优先级高于读锁，写锁的请求可能会被插入到读锁队列的前面）。

行级锁

行级锁可以最大程度地支持并发处理，同时也带来了最大的锁开销问题。行级锁只在存储引擎中进行实现，服务层完全不了解存储引擎中的实现。