高性能MySQL（一）：MySQL架构与历史

前言

我准备开一个新的系列，这是我以前接触不多的新领域，叫性能调优。
刷博客的时候，看到“性能调优”这个词的时候，我整个人都愣住了，感觉时间停滞了。
我发现，我根本不知道我写的项目代码，性能属于什么水平，就算是烂，也不知道到底有多烂。 我使用的中间件，也不知道它们的性能如何。

这样不好。

本系列取材于《高性能MySQL》第三版，是我的学习笔记。

---

MySQL架构与历史

MySQL逻辑架构

第二层架构是MySQL比较有意思的部分，大多数MySQL的核心服务功能都在这一层，包括增删查改以及所有的内置函数。
所有跨存储引擎的功能都在这一层实现，存储过程、触发器、视图等。

第三层包含了存储引擎，负责MySQL中数据的存储和提取。每个存储引擎都有各自的优势和劣势，服务器通过API与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层操作透明。存储引擎不会去解析SQL(InnoDB是个例外，因为MySQL服务器本身没有实现该功能)。不同的存储引擎之间也不会相互通信，而只是简单的响应上层服务器的请求。

---

连接管理

每个客户端都会在服务器进程中拥有一个线程，这个连接的查询只会在这个单独的线程中执行，该线程只能轮流在某个CPU核心或者CPU中运行。
服务器有线程池。所以不需要为每个新来的连接创建或销毁线程。

---

优化与执行

MySQL会解析查询，并创建内部数据结构（解析树），然后对其进行各种优化，包括重写查询、决定表的读取顺序、以及选择合适的索引等。用户可以通过特殊的关键字提示优化器，影响它的决策过程。也可以请求优化器解释优化过程的各个因素，使用户可以知道服务器是如何进行优化决策的，并提供一个参考标准，便于用户重构查询和schema、修改相关配置，使应用尽可能高效的运行。

对于SELECT语句，在解析查询之前，服务器会先检查查询缓存，如果能在其中找到对应的查询，服务器就不必再执行查询解析、优化和执行的整个过程。

---

并发控制

读锁：共享
写锁：排他

其实我真不知道这个读锁存在的意义是什么，以及是否需要实现。

锁粒度

一种提高共享资源并发性的方式就是让锁定对象更有选择性。尽量只锁定需要修改部分的数据，而不是所有的资源。更理想的方式是：只对会修改的数据片进行精确的锁定。

问题是管理锁也需要系统开销，所谓的锁策略，就是在锁的开销和数据的安全之间寻找一个平衡。

表锁

表锁是MySQL中最基本的锁策略，也是开销最小的策略。它会锁定整张表。

行级锁

行级锁可以最大程度的支持并发处理（同时也带来了最大的锁开销）

---

事务

事务就是一组原子性的SQL查询，事务内的语句，要么全部执行成功，要么全部回滚。

ACID：

原子性：一个事务必须被视为一个不可分割的最小工作单元。
一致性：就是回滚。
隔离性：一个事务所做的修改在提交之前，对其他事务是不可见的。
持久性：事务一旦提交，其所做的修改就会永久的保存到数据库中。

隔离级别

隔离性其实比想象的更要复杂。下面简单介绍一下四种隔离级别。

未提交读：性能消耗又大，又没有什么卵用。除非真的有很必要的理由，不然就别看了。

提交读：就是上面那个定义，提交了才能读，所以叫提交读。

可重复读：解决了脏读的问题，但是无法解决幻读的问题。所谓幻读，是指当某个事物在读取某个范围内的纪录时，另一个事务又在该范围内插入了新的纪录，当之前的事务再次读取该范围的纪录时，会产生幻行。InnoDB和XtraDB存储引擎通过多版本并发控制解决了幻读的问题。
可重复度是MySQL默认事务隔离级别。

可串行化：这个是最高的隔离级别了，它通过强制要求事务串行执行，避免了前面所说的幻读问题。但是呢，消耗太大了，所以只有在非常需要保证数据的一致性且可以接受没有并发的情况下，考虑使用该级别。

---

事务日志

事务日志可以有效提高事务的效率，就是预写实日志。
使用事务日志，存储引擎在修改表的数据的时候，只需要修改其内存拷贝，再把该修改行为纪录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。事务日志采用的是追加的方式，因此写日志的操作是磁盘上一小块儿区域内的顺序I/O，而不像随机I/O要在磁盘的多个地方移动磁头。
所以采用事务日志的方式相对来说要快很多。事务日志持久以后，内存中被修改的数据可以在后台慢慢的刷回到磁盘。
如果数据的修改已经纪录到事务日志并持久化，当数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动回复这部分修改的数据。
（参考AOF）

---