MySQL架构与特性（一）

逻辑架构

本系列主要适用于对mysql有一定认识，使用经验在1年以上的同学，本系列不会去讲解基本语法，sql查询等内容，主要是性能优化角度深入理解。个人能力有限，有不足之处望批评指正。

本章主要概要的描述MySQL的服务器架构，并发控制，事务，存储引擎间特性和区别等

• 逻辑架构图

1. 上层架构并不是mysql独有的，大多数基于网络的客户端工资都有类似架构，比如连接处理，授权认证，安全等。

2. 第二层架构包括了mysql的核心服务，查询解析、分析、优化、缓存以及所有的内置函数（日期，时间，数学等）所有跨存储引擎的功能都在这一层实现：存储过程，触发器，视图等。

3. 第三层包含了存储引擎，负责mysql中数据的存储和提取。存储引擎不会去解析sql，不同的存储引擎直接不会相互通信，只是简单地响应上层服务器的请求。

• mysql的优化与执行

1. mysql会解析查询，对其优化，包括重写查询、决定表的读取顺序、选择合适的索引等，用户可以用关键字（hint）提示优化器，影响它的决策过程。可以使用 explain 请求优化器解释优化过程的各个因素。
2. 对于select语句，会在解析查询之前，建检查查询缓存（Query Cache）如果缓存命中直接返回，否则执行查询，然后将结果写入缓存。

• 并发控制

   mysql的并发控制分服务器层和存储引擎层
  

1. 读写锁

   ✧ 读锁是共享的，也称共享锁（shared lock）相互不阻塞，多个客户在同一时刻读取同一资源互不干扰。
   ✧ 写锁是排他的，也称排它锁 （exclusive lock），一个写锁会阻塞其他的写锁和读锁。

   写锁比读锁有更高的优先级，写锁可以插入到读锁队列的前面。
   

2. 锁粒度

   提高共享资源高并发的方式是让锁定的对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。更理想的方式是，只对会修改的数据片进行精确的锁定。任何时候，在给定的资源上，锁定的数据越少，则系统的并发性就越高。

   加锁也是需要消耗资源的。锁的各种开销，获得锁、解锁、判断锁是否解除等都会增加系统的开销，因此在并发性的选择上需要选择合适的策略。
   

3. 锁策略

   所谓锁策略，就是在锁的开销和数据的安全性之间寻求平衡。大多数的商业数据库系统一般都在表上施加行级锁来提高性能。

   常见的锁策略有：表锁和行级锁。
   

• 表锁

  表锁是mysql的最基本的所策略，并且是开销最低的策略。他会锁定整张表，用户在对表进行写操作前，需要先获得写锁，这会阻塞其他用户对该表的所有读写操作。（写锁比读锁有更高的优先级）
  存储引擎可以管理自己的锁，但MySQL也会有自己的策略，例如：服务器会为诸如Alter table之类的语句使用表锁，而忽略存储引擎的锁机制。
  显式指定：

   ✓ lock tables
   ✓ unlock tables;
  

• 行级锁

  行级锁可以最大程度的支持并发处理，常见的InnoDB、XtraDB等，行级锁只在存储引擎层实现
  显式指定：

   ✓ select ... lock in share mode;
   ✓ select ... for update;
  

MySQL架构与特性（二）