概述
自从学习 MySQL 以来,我们一直听到或者看到很多优化建议,比如说不要用 select * 查询,用什么字段就查什么字段;建议用自增主键来作为表的主键,等等。这些建议听得很多感觉都成了 MySQL 开发的常识了,但是对于这些优化建议,我们有没有想过为什么要这么做呢?这篇博文我们从 MySQL 的原理出发,来解释下为什么有这些优化建议?本文实验环境 MySQL 5.7.25
预备知识
B+ 树索引
MySQL 的默认存储引擎 InnoDB 使用 B+ 树来存储数据的,所以在分析优化建议之前,我们有必要了解 B+ 树索引的基本原理。
上图是一个 B + 树索引示意图(B+ 树的定义可以看这里),每个节点表示一个磁盘块,也可以理解为数据库中的页。我们来分析下 B+ 树索引的查找过程,如果我要查询主键为 35 的数据,索引会怎么走呢?首先会判断 35 小于根节点 37 ,继续查询左子树,判断 35 大于 22 和 33 那么进入其右子树,找到了叶子节点 33 ,继续遍历找到了 35 ,最后取出其 data 即可。在索引的情况下,查询 35 只用了3次 IO 操作,这是非常高效的。在真实的场景下,3层的b+树可以表示上百万的数据,如果上百万的数据查找只需要三次IO,性能提高将是巨大的,如果没有索引,每个数据项都要发生一次IO,那么总共需要百万次的IO,显然成本非常非常高。上图中也是体现了只要维持树的高度足够低,IO 操作就会足够少,IO次数少,查询性能就会高。
Explain 执行计划
上图就是一个 explian 执行计划,先看看上面各个字段的含义是什么?id: Query Optimizer 所选定的执行计划中的查询编号。
select_type: 所使用的查询类型,主要有几种查询类型:table: 显示执行这一步所访问的数据库中的表的名称。
partitions: 查询分区表匹配的分区,非分区表显示 NULL 。
type: 查询表所使用的方式,类型如下:他们的性能由好到差依次是:system > const > eq_ref > ref > full_text > ref_or_null > unique_subquery > index_subquery > range > index_merge > index > all 。
possible_keys: 查询可能用到的索引。
key_len: 用到的索引长度。
ref: 展示将那些列或者常量与命中的索引比较。
rows: 执行这次查询扫描的行数。
filtered: 过滤行数百分比,最大值是100,当显示100时候,表示没有过滤行, rows显示了检查的估计行数,乘以过滤百分比将显示与下表连接的行数。例如,如果行数为1000,过滤条件为50.00(50%),则与下表联接的行数为1000×50%= 500。
extra: 执行查询额外的条件。
掌握了前面这些前置知识,我们来用这些知识分析下经常建议我们的那些MySQL优化建议。
为什么建议使用自增主键
当我们每次建立表的时候都在考虑是用自增主键呢?还是用 UUID 呢?但是从性能考虑我们还是建议使用自增 Id,为什么呢?主要是由于 MySQL B+ 树索引性质决定的,数据的新增是要更新索引的,也就是要更新 B+ 树。换句话说,使用自增Id 和 非自增 Id 哪种更新 B+ 树更快,成本更低,谁就是更优的选择。我们来模拟下自增 Id 插入和非自增 Id 插入情况。
自增Id 插入情况: 我们在一个已经有10条数据的 B + 数上插入2条数据,分别是10和11,我们看看树是如何变化的。
我们这里可以发现两个特点:
1、自增的数据插入影响的范围永远只有最右的子树,要么直接在子树插入节点,要么就是子树分裂,影响其父节点。
2、除了最右子树,其他子树的节点都是满的。
上面两个特点有什么影响呢?我们根据前面 B+ 树索引示意图可以知道,每个点都是一个磁盘块,操作每个节点相当于进行一次 IO,由于每次插入影响的节点只有最右子树,那么磁盘 IO 的范围就可控;最重要一点是除最右子树,其他子树的节点都是满的,这种情况,叶子节点数据的物理连续性会更好, 根据局部性原理,查询性能也会更高。
非自增 Id 插入情况:
非自增 Id 插入特点对比自增 Id 插入我们很容易就能知道:
1、插入影响节点不可控,无法预知。
2、每个子树都存在叶子节点不满的情况。
按照之前的分析思路,我们也就知道了非自增 Id 插入有什么性能劣势了。由于插入数据影响节点不可控,导致节点分裂的情况就会更频繁,节点分裂也是 IO 操作,性能自然受到影响。子树的叶子节点不满,会导致叶子节点物理连续性不好。最后如果我们是UUID的话,Id 过长,会占用节点空间,每个页能存储的节点变少,页分裂变多,性能也会受到影响。这也是为什么建议使用自增主键的原因。
为什么不要使用 select * 查询
我们经常听到查询表,只要查询自己想要的字段,不需要的字段就不要查询,严禁使用 select *,我们能想到很直观的理由就是,数据库要帮你翻译成每个字段名去查询,接着查询多余的字段会占用内存,带宽等资源。这确实是一个理由,而且这个理由很重要,但是我这里想说的是另外一个原因,覆盖索引。我之前的一篇索引文章也介绍了覆盖索引,感兴趣的同学可以点击这里。覆盖索引的意思是指查询使用联合索引覆盖了要查询的字段,这样数据库不用去进行回表,从而减少IO,提高性能。
这里我用MySQL官方给的示列数据进行一个实验,数据地址下载可以点击这里。
我选择 employees 表数据进行演示,默认数据是没有联合索引的,我们加上一个联合索引:
---employee表结构-----------
+------------+---------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+---------------+------+-----+---------+-------+
| emp_no | int(11) | NO | PRI | NULL | |
| birth_date | date | NO | | NULL | |
| first_name | varchar(14) | NO | MUL | NULL | |
| last_name | varchar(16) | NO | | NULL | |
| gender | enum('M','F') | NO | | NULL | |
| hire_date | date | NO | | NULL | |
+------------+---------------+------+-----+---------+-------+
ALTER TABLE employees.employees add Index `idx_first_name_last_name` (first_name,last_name);
查看该表索引情况:show index from employees.employees;
表已经成功创建了first_name 和 last_name的符合索引,我们开启 profiles 监控 SQL 执行的情况。
SET SESSION profiling = 1;
然后分别执行以下SQL
SELECT first_name,last_name FROM employees.employees WHERE first_name='Eric';
SELECT * FROM employees.employees WHERE first_name='Eric';
查看Profiles;
这里我们看到使用 select * 比 select 字段慢了4倍左右,为什么会这样呢?我们看看执行计划。
我们看到两者的执行计划几乎一样,只有 Extra 有区别,使用字段的 Extra 显示 using index,这就告诉你只使用索引就找到了想要的数据,因为你的索引就是用 first_name 和 last_name 建立的, 而 select * 它还需要查询 gender和hire_date字段(主键字段不用额外查,辅助索引指向的就是主键),所以它不能不进行回表查询其他字段,性能差异也是这里。
总结
本文从原理上分析了我们日常的两点建议,为什么建议使用自增主键?为什么不建议使用 select * 查询?其实主要最终的原因还是和索引相关,既然我们用索引来提高我们的效率就要充分利用它,下面是知识点总结:
1、B+ 树查询的效率高低是受其树高影响,树的高度越低,查询IO次数越少,性能相对也就越高。
2、执行计划的类型由好到差依次是:system > const > eq_ref > ref > full_text > ref_or_null > unique_subquery > index_subquery > range > index_merge > index > all 。
3、自增主键的好处就是连续,插入维护的成本相对较低,同时子树的叶子节点大部分是满节点,物理连续性好,查询性能更优。
4、UUID 主键长度过长,导致单个子节点存储的主键变少,更平凡的出发页分裂,影响性能,这也是为什么建议索引不要太长的原因。
5、覆盖索引是很好的优化技巧,可以让查询直接通过索引返回数据,而不用回表,减少IO,提升性能。
参考
来源:开源中国
作者:木木匠