mysql教學欄位介紹執行計劃explain與索引資料結構

MySQL 執行計劃explain與索引資料結構推演

準備工作

先建好資料庫表，示範用的MySQL表，建表語句：

CREATE TABLE `emp` (  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',  `empno` int(11) DEFAULT NULL COMMENT '雇员工号',  `ename` varchar(255) DEFAULT NULL COMMENT '雇员姓名',  `job` varchar(255) DEFAULT NULL COMMENT '工作',  `mgr` varchar(255) DEFAULT NULL COMMENT '经理的工号',  `hiredate` date DEFAULT NULL COMMENT '雇用日期',  `sal` double DEFAULT NULL COMMENT '工资',  `comm` double DEFAULT NULL COMMENT '津贴',  `deptno` int(11) DEFAULT NULL COMMENT '所属部门号',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='雇员表';CREATE TABLE `dept` (  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',  `deptno` int(11) DEFAULT NULL COMMENT '部门号',  `dname` varchar(255) DEFAULT NULL COMMENT '部门名称',  `loc` varchar(255) DEFAULT NULL COMMENT '地址',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='部门表';CREATE TABLE `salgrade` (  `id` int(11) NOT NULL COMMENT '主键',  `grade` varchar(255) DEFAULT NULL COMMENT '等级',  `lowsal` varchar(255) DEFAULT NULL COMMENT '最低工资',  `hisal` varchar(255) DEFAULT NULL COMMENT '最高工资',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='工资等级表';CREATE TABLE `bonus` (  `id` int(11) NOT NULL COMMENT '主键',  `ename` varchar(255) DEFAULT NULL COMMENT '雇员姓名',  `job` varchar(255) DEFAULT NULL COMMENT '工作',  `sal` double DEFAULT NULL COMMENT '工资',  `comm` double DEFAULT NULL COMMENT '津贴',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='奖金表';复制代码

登入後複製

後續執行計劃，查詢優化，索引優化等等知識的演練，基於以上幾個表來操作。

MySQL執行計劃

要進行SQL調優，你得知道要調優的SQL語句是怎麼執行的，查看SQL語句的具體執行過程，以加快SQL語句的執行效率。

可以使用explain SQL語句來模擬最佳化器執行SQL查詢語句，從而知道MySQL是如何處理SQL語句的。

關於explain可以看看官網介紹。

explain的輸出格式

mysql> explain select * from emp;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+|  1 | SIMPLE      | emp   | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+复制代码

登入後複製

欄位id，select_type等欄位的解釋：

##tableThe table for the output row（輸出該行的表名）#partitionsThe matching partitions（匹配的分區）typeThe join type（連接類型）#possible_keysThe possible indexes to choose（可能的索引選擇） keyThe index actually chosen（實際選擇的索引）key_lenThe length of the chosen key（所選鍵的長度）ref#The columns compared to the index（與索引比較的列）#rowsEstimate of rows to be examined（檢查的預估行數）##filteredextra

id

select查询的序列号，包含一组数字，表示查询中执行select子句或者操作表的顺序。

id号分为三类：

如果id相同，那么执行顺序从上到下

mysql> explain select * from emp e join dept d on e.deptno = d.deptno join salgrade sg on e.sal between sg.lowsal and sg.hisal;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                                              |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
|  1 | SIMPLE      | e     | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL                                               |
|  1 | SIMPLE      | d     | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | Using where; Using join buffer (Block Nested Loop) |
|  1 | SIMPLE      | sg    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+复制代码

登入後複製

这个查询，用explain执行一下，id序号都是1，那么MySQL的执行顺序就是从上到下执行的。

如果id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行

mysql> explain select * from emp e where e.deptno in (select d.deptno from dept d where d.dname = 'SALEDept');
+----+--------------+-------------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+| id | select_type  | table       | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                                              |
+----+--------------+-------------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+|  1 | SIMPLE       | <subquery2> | NULL       | ALL  | NULL          | NULL | NULL    | NULL | NULL |   100.00 | NULL                                               |
|  1 | SIMPLE       | e           | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    2 |    50.00 | Using where; Using join buffer (Block Nested Loop) |
|  2 | MATERIALIZED | d           | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | Using where                                        |
+----+--------------+-------------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+复制代码</subquery2>

登入後複製

这个例子的执行顺序是先执行id为2的，然后执行id为1的。

id相同和不同的，同时存在：相同的可以认为是一组，从上往下顺序执行，在所有组中，id值越大，优先级越高，越先执行

还是上面那个例子，先执行id为2的，然后按顺序从上往下执行id为1的。

select_type

主要用来分辨查询的类型，是普通查询还是联合查询还是子查询。

Column	Meaning
#id	The `SELECT` identifier（此SELECT識別符)
select_type	The `SELECT` 型態（該SELECT類型）








#Percentage of rows filtered by table condition（按表格條件篩選的行百分比）
#Additional information（附加資訊）

`select_type` Value	JSON Name	Meaning
SIMPLE	None	Simple SELECT (not using UNION or subqueries)
PRIMARY	None	Outermost SELECT
UNION	None	Second or later SELECT statement in a UNION
DEPENDENT UNION	dependent (true)	Second or later SELECT statement in a UNION, dependent on outer query
UNION RESULT	union_result	Result of a UNION.
SUBQUERY	None	First SELECT in subquery
DEPENDENT SUBQUERY	dependent (true)	First SELECT in subquery, dependent on outer query
DERIVED	None	Derived table
MATERIALIZED	materialized_from_subquery	Materialized subquery
UNCACHEABLE SUBQUERY	cacheable (false)	A subquery for which the result cannot be cached and must be re-evaluated for each row of the outer query
UNCACHEABLE UNION	cacheable (false)	The second or later select in a UNION that belongs to an uncacheable subquery (see UNCACHEABLE SUBQUERY)

SIMPLE 简单的查询，不包含子查询和union

mysql> explain select * from emp;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+|  1 | SIMPLE      | emp   | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+复制代码

登入後複製

primary 查询中若包含任何复杂的子查询，最外层查询则被标记为Primary
union 若第二个select出现在union之后，则被标记为union

+----+--------------+------------+------------+------+---------------+------+---------+------+------+----------+-----------------+复制代码

登入後複製

这条语句的select_type包含了primary和union

dependent union 跟union类似，此处的depentent表示union或union all联合而成的结果会受外部表影响
union result 从union表获取结果的select
dependent subquery subquery的子查询要受到外部表查询的影响

+----+--------------------+------------+------------+------+---------------+------+---------+------+------+----------+-----------------+复制代码

登入後複製

这条SQL执行包含了PRIMARY、DEPENDENT SUBQUERY、DEPENDENT UNION和UNION RESULT

subquery 在select或者where列表中包含子查询

举例：

mysql> explain select * from emp where sal > (select avg(sal) from emp) ;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+|  1 | PRIMARY     | emp   | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    33.33 | Using where |
|  2 | SUBQUERY    | emp   | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |   100.00 | NULL        |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+复制代码

登入後複製

DERIVED from子句中出现的子查询，也叫做派生表
MATERIALIZED Materialized subquery？
UNCACHEABLE SUBQUERY 表示使用子查询的结果不能被缓存

例如：

mysql> explain select * from emp where empno = (select empno from emp where deptno=@@sort_buffer_size);
+----+----------------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+| id | select_type          | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+----------------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+|  1 | PRIMARY              | emp   | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |   100.00 | Using where |
|  2 | UNCACHEABLE SUBQUERY | emp   | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    25.00 | Using where |
+----+----------------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+复制代码

登入後複製

uncacheable union 表示union的查询结果不能被缓存

table

对应行正在访问哪一个表，表名或者别名，可能是临时表或者union合并结果集。

如果是具体的表名，则表明从实际的物理表中获取数据，当然也可以是表的别名

表名是derivedN的形式，表示使用了id为N的查询产生的衍生表

当有union result的时候，表名是union n1,n2等的形式，n1,n2表示参与union的id

type

type显示的是访问类型，访问类型表示我是以何种方式去访问我们的数据，最容易想到的是全表扫描，直接暴力的遍历一张表去寻找需要的数据，效率非常低下。

访问的类型有很多，效率从最好到最坏依次是：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

一般情况下，得保证查询至少达到range级别，最好能达到ref

all 全表扫描，一般情况下出现这样的sql语句而且数据量比较大的话那么就需要进行优化

通常，可以通过添加索引来避免ALL

index 全索引扫描这个比all的效率要好，主要有两种情况：
- 一种是当前的查询时覆盖索引，即我们需要的数据在索引中就可以索取
- 一是使用了索引进行排序，这样就避免数据的重排序
range 表示利用索引查询的时候限制了范围，在指定范围内进行查询，这样避免了index的全索引扫描，适用的操作符： =, , >, >=,

官网上举例如下：

SELECT * FROM tbl_name WHERE key_column = 10;

SELECT * FROM tbl_name WHERE key_column BETWEEN 10 and 20;

SELECT * FROM tbl_name WHERE key_column IN (10,20,30);

SELECT * FROM tbl_name WHERE key_part1 = 10 AND key_part2 IN (10,20,30);

index_subquery 利用索引来关联子查询，不再扫描全表

value IN (SELECT key_column FROM single_table WHERE some_expr)

unique_subquery 该连接类型类似与index_subquery，使用的是唯一索引

value IN (SELECT primary_key FROM single_table WHERE some_expr)

index_merge 在查询过程中需要多个索引组合使用
ref_or_null 对于某个字段既需要关联条件，也需要null值的情况下，查询优化器会选择这种访问方式

SELECT * FROM ref_table

WHERE key_column=expr OR key_column IS NULL;

fulltext 使用FULLTEXT索引执行join
ref 使用了非唯一性索引进行数据的查找

SELECT * FROM ref_table WHERE key_column=expr;

SELECT * FROM ref_table,other_table WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table WHERE ref_table.key_column_part1=other_table.column AND ref_table.key_column_part2=1;

eq_ref 使用唯一性索引进行数据查找

SELECT * FROM ref_table,other_table WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table WHERE ref_table.key_column_part1=other_table.column AND ref_table.key_column_part2=1;

const 这个表至多有一个匹配行

SELECT * FROM tbl_name WHERE primary_key=1;

SELECT * FROM tbl_name WHERE primary_key_part1=1 AND primary_key_part2=2;

例如：

mysql> explain select * from emp where id = 1;
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+|  1 | SIMPLE      | emp   | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+复制代码

登入後複製

system 表只有一行记录（等于系统表），这是const类型的特例，平时不会出现

possible_keys

显示可能应用在这张表中的索引，一个或多个，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用

key

实际使用的索引，如果为null，则没有使用索引，查询中若使用了覆盖索引，则该索引和查询的select字段重叠

key_len

表示索引中使用的字节数，可以通过key_len计算查询中使用的索引长度，在不损失精度的情况下长度越短越好

ref

显示索引的哪一列被使用了，如果可能的话，是一个常数

rows

根据表的统计信息及索引使用情况，大致估算出找出所需记录需要读取的行数，此参数很重要，直接反应的sql找了多少数据，在完成目的的情况下越少越好

extra

包含额外的信息

using filesort 说明mysql无法利用索引进行排序，只能利用排序算法进行排序，会消耗额外的位置
using temporary 建立临时表来保存中间结果，查询完成之后把临时表删除
using index 这个表示当前的查询是覆盖索引的，直接从索引中读取数据，而不用访问数据表。如果同时出现using where 表明索引被用来执行索引键值的查找，如果没有，表示索引被用来读取数据，而不是真的查找
using where 使用where进行条件过滤
using join buffer 使用连接缓存
impossible where where语句的结果总是false

MySQL索引基本知识

想要了解索引的优化方式，必须要对索引的底层原理有所了解。

索引的优点

大大减少了服务器需要扫描的数据量
帮助服务器避免排序和临时表
将随机io变成顺序io（提升效率）

索引的用处

快速查找匹配WHERE子句的行
从consideration中消除行,如果可以在多个索引之间进行选择，mysql通常会使用找到最少行的索引
如果表具有多列索引，则优化器可以使用索引的任何最左前缀来查找行
当有表连接的时候，从其他表检索行数据
查找特定索引列的min或max值
如果排序或分组时在可用索引的最左前缀上完成的，则对表进行排序和分组
在某些情况下，可以优化查询以检索值而无需查询数据行

MySQL 執行計劃explain與索引資料結構推演

MySQL索引数据结构推演

索引用于快速查找具有特定列值的行。

如果没有索引，MySQL必须从第一行开始，然后通读整个表以找到相关的行。

表越大花费的时间越多，如果表中有相关列的索引，MySQL可以快速确定要在数据文件中间查找的位置，而不必查看所有数据。这比顺序读取每一行要快得多。

既然MySQL索引能帮助我们快速查询到数据，那么它的底层是怎么存储数据的呢？

几种可能的存储结构

hash

hash表的索引格式

hash表儲存資料的缺點：

利用hash儲存的話需要將所有的資料檔案加入內存，比較耗費記憶體空間
如果所有的查詢都是等值查詢，那麼hash確實很快，但是在實際工作環境中範圍查找的資料更多一些，而不是等值查詢，這種情況下hash就不太適合了

事實上，MySQL儲存引擎是memory時，索引資料結構所採用的就是hash表。

二元樹

二元樹的結構是這樣的：

二元樹會因為樹的深度而造成數據傾斜，如果樹的深度太深，會造成io次數變多，影響資料讀取的效率。

AVL樹 需要旋轉，看圖例：

#紅黑樹 除了旋轉操作還多了一個變色的功能（為了減少旋轉），這樣雖然插入的速度快，但是損失了查詢的效率。

二元樹、AVL樹、紅黑樹 都會因為樹的深度過深而造成io次數變多，影響資料讀取的效率。

再來看B樹

B樹特徵：

所有鍵值分佈在整顆樹中
#搜尋有可能在非葉子結點結束，在關鍵字全集內做一次查找,效能逼近二分查找
每個節點最多擁有m個子樹
根節點至少有2個子樹
分支節點至少擁有m/2子樹（除根節點和葉子節點外都是分支節點）
所有葉子節點都在同一層、每個節點最多可以有m -1個key，並且以升序排列

圖例說明：

每個節點佔用一個磁碟區塊，一個節點上有兩個升序排序的關鍵字和三個指向子樹根節點的指針，指針儲存的是子節點所在磁碟區塊的位址。

兩個關鍵字分割成的三個範圍域對應三個指標所指向的子樹的資料的範圍域。

以根節點為例，關鍵字為16 和34，P1 指標指向的子樹的資料範圍為小於16，P2 指標指向的子樹的資料範圍為16~34，P3 指標指向的子樹的資料範圍為大於34。

尋找關鍵字過程：

1、根據根節點找到磁碟區塊 1，讀入記憶體。【磁碟 I/O 操作第 1 次】

2、比較關鍵字 28 在區間（16,34），找出磁碟區塊 1 的指標 P2。

3、根據 P2 指標找到磁碟區塊 3，讀入記憶體。【磁碟 I/O 操作第 2 次】

4、比較關鍵字 28 在區間（25,31），找出磁碟區塊 3 的指標 P2。

5、根據 P2 指標找到磁碟區塊 8，讀入記憶體。【磁碟 I/O 操作第 3 次】

6、在磁碟區塊 8 中的關鍵字清單中找到關鍵字 28。

由此，我們可以得知B樹儲存的缺點：

每個節點都有key，同時也包含data，而每個頁儲存空間是有限的，如果data比較大的話會導致每個節點儲存的key數量變小
當儲存的資料量很大的時候會導致深度較大，增大查詢時磁碟io次數，進而影響查詢效能

那麼MySQL索引資料結構是什麼

官網：Most MySQL indexes (PRIMARY KEY, UNIQUE, INDEX, and FULLTEXT) are stored in B-trees

不要誤會，其實MySQL索引的儲存結構就是B 樹，上面我們一頓分析，知道B樹是不合適的。

mysql索引資料結構---B Tree

B Tree是在BTree的基礎之上所做的最佳化，變更如下：

#1、B Tree每個節點可以包含更多的節點，這個做的原因有兩個，第一個原因是為了降低樹的高度，第二個原因是將資料範圍變成多個區間，區間越多，資料檢索越快。

2、非葉子節點儲存key，葉子節點儲存key和資料。

3、葉子節點兩兩指標互相連接（符合磁碟的預讀特性），順序查詢效能更高。

B 樹儲存尋找示意圖：

注意：

在B+Tree上有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构。

因此可以对 B+Tree 进行两种查找运算：一种是对于主键的范围查找和分页查找，另一种是从根节点开始，进行随机查找。

由于B+树叶子结点只存放data，根节点只存放key，那么我们计算一下，即使只有3层B+树，也能制成千万级别的数据。

你得知道的技（zhuang）术（b）名词

假设有这样一个表如下，其中id是主键：

mysql> select * from stu;
+------+---------+------+| id   | name    | age  |
+------+---------+------+|    1 | Jack Ma |   18 |
|    2 | Pony    |   19 |
+------+---------+------+复制代码

登入後複製