高性能MySQL第三版笔记

第1章 MySQL架构与历史

1.1 MySQL逻辑架构

1.1 MySQL逻辑架构

1.2 并发控制

1.2.1 读写锁

读共享，写互斥，写者优先读者

1.2.2 锁粒度

尽量只锁定需要修改的数据，而不是所有的数据。锁定的数据量越少，则系统的并发程度越高。

但是加锁也需要消耗资源。锁的操作，包括获取锁，检查锁是否已经解除，释放锁等，都会增加系统的开销。

所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡，两种最重要的锁策略：表锁的行级锁。

表锁：

行级锁：

1.3 事务

事务是一组原子性的SQL查询，或者说一个独立的工作单元。
如果数据库引擎能偶成功地对数据库应用该组查询的全部语句，那么就执行该组查询。如果其中有任何一条语句因为崩溃或其他原因无法执行，那么所有的语句都不会执行。

事务ACID特性：原子性，一致性，隔离性，持久性。

1.3.1 隔离级别

1.3.2 死锁

1.3.3 事务日志

1.3.4 MySQL中的事务

MySQL默认采用自动提交（AUTOCOMMIT）模式。也就是说，如果不是显式地开启一个事务，则每个查询都被当做一个事务执行提交操作。

1.4 多版本并发控制

MVCC只在可重复读和提交读这两个隔离级别下工作。

1.5 MySQL的存储引擎

第3章 服务器性能剖析

3.1 性能优化简介

将性能定义为完成某件任务所需要的时间度量，换句话说，性能即响应时间。

性能优化就是在一定的工作负载下尽可能地降低响应时间。

第4章 Schema与数据类型优化

4.3 范式和反范式

范式的优点：

第5章 创建高性能的索引

索引是存储引擎用于快速找到记录的一种数据结构。

索引对于良好的性能非常关键。尤其是当表中的数据量越来越大时，索引对性能的影响愈发重要。

索引优化应该是对查询性能优化最有效的手段了。索引能够轻易将查询性能提高几个数量级。

5.1 索引基础

5.1.1 索引的类型

索引有很多种类型。索引是在存储引擎层而不是服务器层实现的。

B-Tree索引

实际上很多存储引擎包括InnoDB引擎使用的是B+Tree，即每一个叶子节点都包含指向下一个叶子节点的指针，从而方便叶子节点的范围遍历。

基于B+Tree的索引结构：

B-Tree索引能够加快访问数据的速度，因为存储引擎不再需要进行全表扫描来获取需要的数据，取而代之的是从索引的根节点开始进行搜索。根节点的槽中存放了指向子节点的指针，存储引擎根据这些指针指向下层查找。通过比较节点页的值和要查找的值可以找到合适的指针进入下层子节点，这些指针实际上定义了子节点页中值的上限和下限。最终存储引擎要么是找到对应的值，要么该记录不存在。

叶子节点比较特别，它们的指针指向的是被索引的数据，而不是其他的节点页。

哈希索引：

InnoDB并不显式支持哈希索引，InnoDB会自适应创建哈希索引，不会受用户控制。

Memory引擎显式支持哈希索引。

下面来看一个例子，假设有如下表：

全文索引：

5.2 索引的优点

5.3 高性能的索引策略

5.3.1 独立的列

5.3.5 聚簇索引

下图展示了聚簇索引中的记录是如何存放的。叶子页包含了行的全部数据，但是节点页只包含了索引列。

InnoDB通过主键聚集数据，这也就是说上图中的“被索引的列”就是主键列。

聚集数据的优点：

非聚簇索引（二次索引）：

5.4 索引案例学习

第6章 查询性能优化

查询优化、索引优化、库表结构优化需要齐头并进，一个不落。

6.1 为什么查询速度会慢

6.2 慢查询基础：优化数据访问

6.2.1 是否向数据库请求了不需要的数据

有些查询会请求超过实际需要的数据，然后这些多余的数据会被应用程序丢弃。这会给MySQL服务器带来额外的负担，并增加网络开销，另外也会消耗应用服务器的CPU和内存资源。

这里有一些典型的案例：

查询不需要的记录：

多表关联时返回全部列：

总是取出全部列：

重复查询相同的数据：

6.4 查询执行的基础

当向MySQL发送一个请求的时候，MSQL到底做了些什么？