《高性能MYSQL》第三版读书笔记（一）

mysql架构与历史

1.逻辑架构

1.1 第一层服务

最上层服务主要负责连接处理、授权认证、安全等，并非mysql独有功能，大部分基于网络的客户端/服务器的工具都有此功能。

1.1.1 连接管理与安全性

每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询只会在这个单独的线程中执行，该线程只能轮流在cpu核心或者cpu中运行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或者销毁线程（mysql5.5及以上版本支持线程池插件）。
当应用连接到服务时，服务器需要对其进行认证。认证基于原始主机信息和密码。连接成功后会验证该应用是否有执行某个操作的权限。

1.2 第二层服务

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

1.2.1 优化和执行

mysql会解析查询，并创建内部数据结构，然后对其进行各种优化，如：重写查询、决定表的读取顺序、选取合适的索引等。用户可以通过特殊的关键字提示优化器，影响它的决策过程。也可以请求优化器解释（explain）优化的过程，使用户了解优化器如何进行决策，并提供一个基准参考。
优化器并不关心表使用的存储引擎，但是存储引擎对优化查询时有影响的。优化器会请求存储引擎表的容量或者某个操作的具体开销信息，以及表数据的统计信息等。
对于查询语句，在解析查询之前，服务器会先去检查查询缓存（Query Cache），如果能从中找到对应的查询，服务器就不再执行查询解析、优化和执行的过程，直接返回缓存中的查询结果集。

1.2.2 并发控制

只要有多个查询在同一时刻修改数据，都会产生并发控制的问题。
读写锁
读锁是共享非阻塞的。多个用户可以在同一时刻读取同一资源，而互不干扰。写锁则是排他的，一个写锁会阻塞其他的写锁和读锁。
锁粒度
一种提高共享资源并发性的方式就是让他锁定的对象更有选择性，尽量只锁定需要修改的部分数据，而不是所有资源。
锁策略在锁的开销和安全性之间寻求平衡。
表锁是mysql中最基本的锁策略，并且是开销最小的策略。表锁会锁定整张表。在对一张表进行写操作前需要先获得写锁，然后进行写操作（插入、删除、更新等），这时会阻塞其他用户对该表的所有读写操作。
写锁比读锁有更高的优先级，一个写锁请求可能会被插入到读锁队列的前面。
mysql服务器会使用各种有效的表锁实现不同的目的，有时会忽略存储引擎的锁机制，如：服务器会为Alter Table 之类的语句使用表锁，而忽略存储引擎的锁机制。
行级锁可以最大程度地支持并发处理，同时也带来了最大的锁开销。行锁在存储引擎层实现（Innodb实现了行锁），服务器层没有实现也不了解存储引擎中的锁实现。

1.3 第三层服务

第三层包含了mysql的存储引擎，负责数据的存储和提取。服务器通过AIPI与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层查询过程透明。存储引擎不会解析sql（例外：Innodb会解析外键，因为mysql服务器未实现该功能），存储引擎之间也不会相互通信。