高性能MySQL（一）

处理/存储相分离

第一层不是MySQL独有，如网络的客户端/服务器的工具或者服务都有类似的架构。如连接处理、授权认证、安全等。
第二层包含大多数核心服务功能。 解析、分析、优化、缓存以及大多数内置函数（时间、日期、数学和加密函数，所有跨储存引擎的功能都在这一层实现：存储过程、触发器视图等等。
第三层包含存储引擎。存储引擎负责数据的存储和提取。

连接管理与安全性

客户端（应用）与MySQL连接时会创建一个线程，连接查询只会在这个进程中执行，会轮流在cpu核心或者CPU中运行，服务器缓存线程，因此不需要为每个连接创建或者销毁进程。
客户端（应用）连接时会对其进行认证，验证其是否有某个特定查询的权限。

优化与执行
MySQL解析查询，创建内部数据结构，然后对其优化，包括重写查询、决定表的读取顺序，以及选择合适的搜索引擎。用户可以通过特殊的关键字提示（hint）优化器，影响他的决策进程，也可以请求优化器解释优化过程中的各个因素，使用户知道服务器是如何优化决策的，提供一个参考基准。
搜索引擎对优化器（优化查询）有一定的影响，优化器会请求存储引擎提供容量或具体操作的开销信息。
对于SELECT 语句，在解析查询前，服务器会先检测查询缓存，如果存在，服务器就不必在执行查询解析、优化和执行的整个过程，而是直接返回缓存中的结果集。

锁策略

MySQL支持多种存储引擎，因此锁策略用于平衡保证储存数据安全与保证并发量的策略不唯一。以下两种最重要的锁策略：
表锁
开销最小的策略，锁定整张表，阻塞其他用户对表的读写操作，优先级比读锁高，可以插到锁队列中读锁的前面。尽管存储引擎可以管理自己的锁，MySQL本身也会通过表锁来实现不同的目的。如ALTER TABLE 中就是使用表锁而忽略了存储引擎中的锁。
行级锁
可支持最大程度的并发，也带来了最大的开销。只在存储引擎中实现，不在MySQL服务层中实现。服务层完全不了解存储引擎中的锁实现。

事务

ACID
原子性 atomicity
一致性 consistency
隔离性 isolation
持久性 durability
需要支持事务的存储引擎

死锁

死锁产生的原因： 数据冲突、由于存储引擎的实现方式
解除死锁：部分或者完全回滚执行因死锁执行的一个事务

事务日志

帮助提高事务的效率。使用事务日志时，只需修改其内存拷贝，再将该修改行为记录到持久在硬盘上的事务日志当中。不用每次将修改的数据本身持久到磁盘。日志操作是磁盘上一小块区域内的顺序I/O,不像随机I/O需要在磁盘上多个地方移动磁头。事务日志持久以后，内存中修改的数据在后台慢慢刷回到磁盘。这种为大多数存储引擎的实现方式，欲写式日志，修改数据需要写两次磁盘。
如果数据修改已经记录到事务并持久化，但数据本身没有写回磁盘。此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。

显示和隐示锁定

隐式：执行COMMIT或者ROLLBACK的时候才会释放，并且为同一时刻释放，INNODB会根据隔离级别在需要的时候加锁
显式：SELECT…LOCK IN SHARE MODE (不属于SQL规范)
除了事务禁用COMMIT ，可以使用LOCK TABLES,其他任何时候不要显示地执行LOCK TABLES

多版本并发控制

MVCC可认为行级锁的一个变种，在很多情况下避免了加锁操作，开销更低，实现了非阻塞的读操作，写操作也只锁定必要的行。MVCC的实现，通过保存数据某个时间的快照来实现。根据事物开始的时间不同，每个事物对同一张表，同一时刻看到的数据可能是不一样的。不同的存储引擎的MVCC实现是不同的。典型的有乐观并发和悲观并发控制。以INNODB的MVCC为例，通过记录后面保存两个隐藏的列来实现。分别保存行创建时间，过期（删除）时间。每开始一个新事物，系统版本号自动递增，保存这两个额外系统版本号，使得大多数读操作不用加锁，该设计读操作简单，性能很好，保证只会读取到符合标准的行。不足之处是每行记录都要额外的存储空间，需要做更多的行检查工作，以及额外的维护工作。
MVCC只在PEPEATABLE READ 和 READ COMMITTED两个隔离级别下工作，其他隔离不兼容，因为READ UNCOMMITTED 总是读取最新的数据行，而SERIALIZBLE 则会对所有读取的行都加锁。

InnoDB存储引擎

默认的MySQL事物型引擎，也是最重要、广泛的存储引擎。被设计用来处理大量的短期事物，短期事物大部分情况是正常提交，很少会被回滚。InnoDB的性能和自动崩溃回复特性，使得他在非事务性存储的需求中也很流行。
采用MVCC来支持高并发，实现了四个标准的隔离级别。默认为REPEATABLE READ(可重复读)，并且通过间隙锁（next-key locking）策略防止幻读的出现。间隙锁使得InnoDB不仅仅锁定查询涉及的行，还会对索引中的间隙进行锁定，以防幻影行的插入。
InnoDB表是基于聚簇索引建立的。聚簇索引对主键索引查询有很高的性能，不过他的二级索引（secondary index，非主键索引）中必须包含主键，如果主键列很大的话，其他的所有索引都会很大。因此，若表上的索引较多的话，主键应该尽可能的小。InnoDB的存储格式是平台独立的，可以将数据和索引文件从Intel平台复制到其他平台。