【高性能MySQL】学习笔记第一章：架构与历史

1 MySQL逻辑架构

• 第一层 处理连接、授权认证、安全等。
• 第二层架构包含MySQL大多数的核心服务，比如查询的解析、分析、优化、缓存和所有的内置函数，跨存储引擎功能都在这一层：存储过程、触发器、试图等。本书后续内容中。这部分也是重点。
• 第三层则是存储引擎，MySQL中数据的存储和提取都是在这一层实现的。各个存储引擎之间是相互独立的。存储引擎提供一些底层函数，而我们对数据库的大多操作都会最后分解成这些函数调用，比如：开始一个事务 或者 根据主键提取一行数据。

1.1 优化与执行

mysql接收到sql，先解析并创建出一颗解析树的结构，然后对其优化，包括重写查询、重排表的读取顺序，选择合适的索引等。这里可以通过explain或者desc来查看执行计划看到优化结果。
优化器和存储引擎无关，select语句在解析之前会查询缓存，如果命中则省去后续流程，直接返回缓存中的数据。

2 并发控制

2.1 读写锁

对于数据的读取来说，即使同一时刻多个用户并发读取也是不会有什么问题的。但是修改删除却是不可控的。这里MySQL用两种类型的锁组成的锁系统来解决。两种锁分别是共享锁和排他锁，也叫读锁和写锁。读锁就是共享的，多个线程同时持有也不会相互阻塞。写锁则不同，在写锁被持有的时候，其他读锁和写锁都将被阻塞。锁的操作对于用户来说是无感知的，正常不需要手动加锁。

2.2 颗粒度

表锁

行级锁

3 事务

ACID

• A（Atomicity ）：原子性，一个事务视为不可分割的最小工作单元，整个事务中所有操作要么全部成功提交，要么全部失败回滚，不可能只执行其中一部分。
• C（Consistency ）：一致性，数据库从一个一致性的状态，换到另外一个一致性的状态，这里是主要是保证了数据的正确性。
• I（Isolation ）：隔离性，在事务最终提交前，对其他事务是不可见的。但是这个是一定的，会被事务的隔离级别影响。
• D（Durability ）：持久性，一旦提交，则所有操作会永久保存到数据库中。即使系统崩溃也不会丢失。这个特性正常情况都是可以保证的，但是如果日志刷新保存的配置修改过，可能会影响。

3.1 隔离级别

• READ UNCOMMITTED（未提交读）
  未提交的数据也对其他事务可见，这种情况叫脏读。
• READ COMMITTED（读提交）
  一个事务从开始到提交之前，所做的所有操作对其他事务都是不可见的。这个级别会出现不可重复度，即 事务中两次相同的查询，得到了不一样的结果。
• REPEATABLE READ（可重复度）
  避免不可重复读的出现，InnoDB和XtraDB引擎通过多版本并发控制（MVCC，Multi-Version Concurrency Control）解决。避免频繁加锁带来的性能开销。但是这种基本还是会出现幻读。
• SERIALIZABLE（可串行化）
  最高的隔离级别。强制事务串行执行，避免幻读问题。会在每行数据都加锁，性能较低。
  

4 多版本并发控制（MVCC）

MVCC只在READ COMMITTED和REPEATABLE READ两个隔离级别下工作。InnoDB中MVCC是一个版本快照来实现的。通过两个隐藏的列来保证是否对事务可见的，一个保存了行的创建时间，一个保存了删除时间。这里时间不是时间值，而是版本号。可以理解为每个事务都是一个新的版本。

5 MySQL的存储引擎

5.1 InnoDB存储引擎

当前MySQL默认的存储引擎。支持事务，行级锁，自动崩溃恢复的特性。InnoDB表是基于聚簇索引简历的，所以表也就是主索引本身。

5.2 MyISAM存储引擎

5.1及之前版本的默认存储引擎。之前全文索引、压缩、空间函数（GIS）等。但是不支持事务和行级锁。也不支持崩溃后安全恢复。对于只读数据或表比较小、可以忍受修复操作，可以使用MyISAM。
数据文件和索引文件，.MYD和.MYI。

还有更多存储引擎就不一一记录了。对于存储引擎的选择，可以简单归纳为一句话：除非需要用到某些InnoDB不具备的特性，并且没有其他办法可以替代，否则都应该优先选择InnoDB引擎