Mysql的架构和历史（一）

Mysql的架构和历史（一）

和其他数据库系统相比，Mysql有点与众不同，它的架构可以在多种不同的场景中应用并发挥好的作用，但同时也会带来一点选择上的困难 ——《高性能的Mysql》

Mysql的逻辑架构

• 简单使用一张图片来描述Mysql的逻辑架构

  

  最上层绝大多数B/S结构的软件都有，在这一层常见的功能有：连接处理，授权认证，安全等等。

  第二层架构是MySQL核心的部分，其主要包括了MySQL的核心服务功能都在这一层，主要包括了查询解析，分析，优化，缓存以及所有内置函数，和所有跨存储引擎的功能都在这一层实现：存储过程，触发器，视图等。

  第三层包含了存储引擎，存储引擎只负责MySQL中的数据存储和提取。和大多数文件系统的一样，每一种存储引擎都有他的优势和劣势。服务器使用同一套API去调用存储引擎，API屏蔽了不同存储引擎的实现过程，对于服务器来说存储引擎的处理过程是黑盒一般，而不同的存储引擎直接也是不会通信，他们能做的只是单纯的响应来自服务器的请求。

• 连接管理与安全

  对于每一个客户端的连接在服务器的进程中都存在一个线程，而每一个客户端的请求都在各自的线程中单独执行，另外服务器只负责缓存线程。

  客户端在通过指定的用户名，原始主机信息和密码连接到服务器，服务器通过对其认证，以及相应的权限管理，去判断指定的用户是否具有指定的数据库中相应的表的查询权限。

• 优化与执行

  MySQL会解析查询，并创建内部数据结构（解析树），然后对其进行各种优化，包括重写查询，决定表结构的读取顺序，以及选择合适的索引等；当然作为客户端也可以使用特殊的关键字来提示优化器，从而影响他的决策过程。

  同时作为优化器而言，他并不关心所需要操作的表使用的是什么存储引擎，但是作为不同的存储引擎对于优化查询还是有影响的。优化器会请求存储引擎提供的容量或某个具体操作的开销信息，以及表数据的统计信息等。比如说innoDB中使用存储引擎的某种索引，可能对一些特定的查询是有优化的。

  最后对于SELECT语句，在解析查询之前，服务器会先查询缓存（Query Cache），如果能直接命中，那么就不需要查询解析，优化和执行的整个过程，而是直接返回查询缓存中的结果集。

并发控制

• 并发控制概述

  假设说现在多个客户端存在多个查询，与此同时某一个客户端对指定的数据进行修改；这个时候就存在了并发控制的问题。MySQL的并发控制主要存在服务器层和存储引擎层。

  MySQL在面对上述问题时，采用锁的机制来处理，简单解释锁的概念，主要是当某一个具体的操作在对指定的表或表中的具体的某一行，那么这个操作会持有具体需要操作的数据（表或某一行）的锁，而其他需要对该表或该行进行的操作；需要等上一个操作执行结束，直到释放该具体操作数据的锁的时候，然后在执行，以上就是锁的概念

• 读写锁

  读写锁主要是读锁和写锁构成，读锁又称之为共享锁（shared lock），写锁又称之为排他锁（exclusive lock）；读锁可以看出来是共享的，所谓的共享指的是当多个客户端在持有读锁时，他们可以同时进行相应的操作（读取数据），但是着多个客户端出现一个写锁的存在时，他会阻塞（立即停止）所有持有读锁的客户端的操作，同时也阻塞了其他持有写锁的操作，直到当前持有写锁的操作执行结束之后

• 粒度锁

  粒度锁旨在提供共享资源并发性的方式就是让锁定对象更有选择性。比如说当我们对一个表中的指定行进行锁定，而不是对整个表进行锁定，这么做的好处就是并发程度更高；当然锁的粒度越细，那么所消耗的资源是越多的，因为对于锁来说他本身也是一种资源，系统在获取锁，检查锁以及释放锁都需要系统开销；那么系统所需管理的锁越多可能就导致系统的性能降低。

  • 表锁（table lock）
    表锁是MySQL中最基本的锁策略，并且开销最小的策略；从字面理解就可以看出来这种锁是对整个表的操作进行锁定；当某一个客户端对指定的表进行进行写操作时，它首先必须获取写锁，阻塞其他客户端对该表进行所有读写操作，只有没有任何客户端持有写锁时，那么所有客户端才能持有读锁，并且所有客户端之间的读锁时互不阻塞的。

  • 行级锁（row lock）
    行级锁可以最大程度支持并发处理，但是与此同时也是最大开销的锁。当然行级锁也是只存在与存储引擎层中实现。