【调优向】MySQL调优必备-执行计划explain与索引数据结构推演

时间  2021-08-14
标签 html mysql git github 算法 sql 数据库 缓存 服务器 markdown 栏目 MySQL 繁體版
原文   原文链接

准备工做

先建好数据库表，演示用的MySQL表，建表语句：html

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

MySQL执行计划

要进行SQL调优，你得知道要调优的SQL语句是怎么执行的，查看SQL语句的具体执行过程，以加快SQL语句的执行效率。git

可使用explain + SQL语句来模拟优化器执行SQL查询语句，从而知道MySQL是如何处理SQL语句的。github

关于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等字段的解释：sql

Column Meaning
id The SELECT identifier（该SELECT标识符）
select_type The SELECT type（ 该SELECT类型）
table The table for the output row（输出该行的表名）
partitions The matching partitions（匹配的分区）
type The join type（链接类型）
possible_keys The possible indexes to choose（可能的索引选择）
key The index actually chosen（实际选择的索引）
key_len The length of the chosen key（所选键的长度）
ref The columns compared to the index（与索引比较的列）
rows Estimate of rows to be examined（检查的预估行数）
filtered Percentage of rows filtered by table condition（按表条件过滤的行百分比）
extra Additional information（附加信息）

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的执行顺序就是从上到下执行的。markdown

  • 若是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                                        |
+----+--------------+-------------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
复制代码

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

  • id相同和不一样的，同时存在：相同的能够认为是一组，从上往下顺序执行，在全部组中，id值越大，优先级越高，越先执行

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

select_type

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

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
mysql> explain select * from emp where deptno = 1001 union select * from emp where sal < 5000;
+----+--------------+------------+------------+------+---------------+------+---------+------+------+----------+-----------------+
| 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 |    25.00 | Using where     |
|  2 | UNION        | emp        | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    33.33 | Using where     |
| NULL | UNION RESULT | <union1,2> | NULL       | ALL  | NULL          | NULL | NULL    | NULL | NULL |     NULL | Using temporary |
+----+--------------+------------+------------+------+---------------+------+---------+------+------+----------+-----------------+
复制代码

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

  • dependent union 跟union相似，此处的depentent表示union或union all联合而成的结果会受外部表影响
  • union result 从union表获取结果的select
  • dependent subquery subquery的子查询要受到外部表查询的影响
mysql> explain select * from emp e where e.empno  in ( select empno from emp where deptno = 1001 union select empno from emp where sal < 5000);
+----+--------------------+------------+------------+------+---------------+------+---------+------+------+----------+-----------------+
| id | select_type        | table      | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra           |
+----+--------------------+------------+------------+------+---------------+------+---------+------+------+----------+-----------------+
|  1 | PRIMARY            | e          | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |   100.00 | Using where     |
|  2 | DEPENDENT SUBQUERY | emp        | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    25.00 | Using where     |
|  3 | DEPENDENT UNION    | emp        | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    25.00 | Using where     |
| NULL | UNION RESULT       | <union2,3> | NULL       | ALL  | NULL          | NULL | NULL    | NULL | NULL |     NULL | Using temporary |
+----+--------------------+------------+------------+------+---------------+------+---------+------+------+----------+-----------------+
复制代码

这条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合并结果集。

  1. 若是是具体的表名，则代表从实际的物理表中获取数据，固然也能够是表的别名
  2. 表名是derivedN的形式，表示使用了id为N的查询产生的衍生表
  3. 当有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的全索引扫描，适用的操做符： =, <>, >, >=, <, <=, IS NULL, BETWEEN, LIKE, or IN()

官网上举例以下：

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索引基本知识

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

索引的优势

  1. 大大减小了服务器须要扫描的数据量
  2. 帮助服务器避免排序和临时表
  3. 将随机io变成顺序io（提高效率）

索引的用处

  1. 快速查找匹配WHERE子句的行
  2. 从consideration中消除行,若是能够在多个索引之间进行选择，mysql一般会使用找到最少行的索引
  3. 若是表具备多列索引，则优化器可使用索引的任何最左前缀来查找行
  4. 当有表链接的时候，从其余表检索行数据
  5. 查找特定索引列的min或max值
  6. 若是排序或分组时在可用索引的最左前缀上完成的，则对表进行排序和分组
  7. 在某些状况下，能够优化查询以检索值而无需查询数据行

索引的分类

索引的分类

MySQL索引数据结构推演

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

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

表越大花费的时间越多，若是表中有相关列的索引，MySQL能够快速肯定要在数据文件中间查找的位置，而没必要查看全部数据。这比顺序读取每一行要快得多。

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

几种可能的存储结构

hash

hash表的索引格式

hash表存储数据的缺点：

  1. 利用hash存储的话须要将全部的数据文件添加到内存，比较耗费内存空间
  2. 若是全部的查询都是等值查询，那么hash确实很快，可是在实际工做环境中范围查找的数据更多一些，而不是等值查询，这种状况下hash就不太适合了

事实上，MySQL存储引擎是memory时，索引数据结构采用的就是hash表。

二叉树

二叉树的结构是这样的：

二叉树

二叉树会由于树的深度而形成数据倾斜，若是树的深度过深，会形成io次数变多，影响数据读取的效率。

AVL树 须要旋转，看图例：

AVL树

红黑树 除了旋转操做还多了一个变色的功能（为了减小旋转），这样虽然插入的速度快，可是损失了查询的效率。

红黑树

二叉树、AVL树、红黑树 都会由于树的深度过深而形成io次数变多，影响数据读取的效率。

再来看一下 B树

B树特色：

  • 全部键值分布在整颗树中
  • 搜索有可能在非叶子结点结束，在关键字全集内作一次查找,性能逼近二分查找
  • 每一个节点最多拥有m个子树
  • 根节点至少有2个子树
  • 分支节点至少拥有m/2颗子树（除根节点和叶子节点外都是分支节点）
  • 全部叶子节点都在同一层、每一个节点最多能够有m-1个key，而且以升序排列

B树存储

图例说明：

每一个节点占用一个磁盘块，一个节点上有两个升序排序的关键字和三个指向子树根节点的指针，指针存储的是子节点所在磁盘块的地址。

两个关键词划分红的三个范围域对应三个指针指向的子树的数据的范围域。

以根节点为例，关键字为 16 和 34，P1 指针指向的子树的数据范围为小于 16，P2 指针指向的子树的数据范围为 16~34，P3 指针指向的子树的数据范围为大于 34。

查找关键字过程：

一、根据根节点找到磁盘块 1，读入内存。【磁盘 I/O 操做第 1 次】

二、比较关键字 28 在区间（16,34），找到磁盘块 1 的指针 P2。

三、根据 P2 指针找到磁盘块 3，读入内存。【磁盘 I/O 操做第 2 次】

四、比较关键字 28 在区间（25,31），找到磁盘块 3 的指针 P2。

五、根据 P2 指针找到磁盘块 8，读入内存。【磁盘 I/O 操做第 3 次】

六、在磁盘块 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的基础之上作的一种优化，变化以下：

一、B+Tree每一个节点能够包含更多的节点，这个作的缘由有两个，第一个缘由是为了下降树的高度，第二个缘由是将数据范围变为多个区间，区间越多，数据检索越快。

二、非叶子节点存储key，叶子节点存储key和数据。

三、叶子节点两两指针相互链接（符合磁盘的预读特性），顺序查询性能更高。

B+树存储查找示意图：

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 |
+------+---------+------+
复制代码

回表

咱们对普通列建普通索引，这时候咱们来查：

select * from stu where name='Pony';
复制代码

因为name建了索引，查询时先找name的B+树，找到主键id后，再找主键id的B+树，从而找到整行记录。

这个最终会回到主键上来查找B+树，这个就是回表。

覆盖索引

若是是这个查询：

mysql> select id from stu where name='Pony';
复制代码

就没有回表了，由于直接找到主键id，返回就完了，不须要再找其余的了。

没有回表就叫覆盖索引。

最左匹配

再来以name和age两个字段建组合索引(name, age)，而后有这样一个查询：

select * from stu where name=? and age=?
复制代码

这时按照组合索引(name, age)查询，先匹配name，再匹配age，若是查询变成这样：

select * from stu where age=?
复制代码

直接不按name查了，此时索引不会生效，也就是不会按照索引查询---这就是最左匹配原则。

加入我就要按age查，还要有索引来优化呢？能够这样作：

  • （推荐）把组合索引(name, age)换个顺序，建(age, name)索引
  • 或者直接把age字段单独建个索引

索引下推

可能也叫谓词下推。。。

select t1.name,t2.name from t1 join t2 on t1.id=t2.id
复制代码

t1有10条记录，t2有20条记录。

咱们猜测一下，这个要么按这个方式执行：

先t1,t2按id合并（合并后20条），而后再查t1.name,t2.name

或者：

先把t1.name,t2.name找出来，再按照id关联

若是不使用索引条件下推优化的话，MySQL只能根据索引查询出t1,t2合并后的全部行，而后再依次比较是否符合所有条件。

当使用了索引条件下推优化技术后，能够经过索引中存储的数据判断当前索引对应的数据是否符合条件，只有符合条件的数据才将整行数据查询出来。

小结

  1. Explain 为了知道优化SQL语句的执行，须要查看SQL语句的具体执行过程，以加快SQL语句的执行效率。
  2. 索引优势及用处。
  3. 索引采用的数据结构是B+树。
  4. 回表，覆盖索引，最左匹配和索引下推。

首发公众号 行百里er ，欢迎老铁们关注阅读指正。代码仓库 GitHub github.com/xblzer/Java…

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程