MySQL高级一 MySQL结构图、各种索引介绍(索引优化)、Explain性能分析、单表查询优化、排序分组优化、锁机制

客官°小女子只卖身不卖艺 2023-01-02 12:22 156阅读 0赞

> 转载自 [NyimaのMySQL高级][Nyima_MySQL]

# MySQL高级 #

> 口诀 :  
> 全职匹配我最爱，最左前缀要遵守  
> 带头大哥不能死，中间兄弟不能断  
> 索引列上少计算，范围之后全失效  
> LIKE 百分写最右，覆盖索引不写  
> 不等空值还有 OR，索引影响要注意  
> VARCHAR 引号不可丢，SQL 优化有诀窍

# 一、Mysql逻辑架构 #

## 1、整体架构 ##

>  *  [了解MySQL体系结构][MySQL]
>  *  [一条SQL语句的坎坷之旅（MySQL底层执行流程分析）][SQL_MySQL]

## 写在开篇： ##

*  对于信息技术人员来说，世界上最受欢迎的开源数据库系统的体系结构非常重要。MySQL在世界范围内受欢迎的原因很多，但主要原因之一是它的体系结构，尽管有许多大型公司，例如Oracle，Microsoft SQL和DB2，但MySQL的体系结构使其成为大多数开发人员的独特且首选的选择。在本文中，我们将讨论MySQL关系数据库管理系统的内部体系结构。本文适用于新手数据库管理员，数据库开发人员，软件开发人员以及对使用MySQL数据库感兴趣的人员。

## 体系结构图：（高清图，请点击放大查看） ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x6YjM0ODExMDE3NQ_size_16_color_FFFFFF_t_70]

## 体系介绍： ##

> **Client Connectors**  
> 接入方。支持很多协议(JDBC、ODBC、.NET、PHP、Python、PERL、C 等)
> 
> **Management Serveices & Utilities**  
> 系统管理和控制工具，mysqldump、 mysql复制集群、分区管理等
> 
> **Connection Pool**  
> 连接池：管理缓冲用户连接、用户名、密码、权限校验、线程处理等需要缓存的需求
> 
> **SQL Interface**  
> SQL接口：接受用户的SQL命令，并且返回用户需要查询的结果
> 
> **Parser**  
> 解析器，SQL命令传递到解析器的时候会被解析器验证和解析。解析器是由Lex和YACC实现的
> 
> **Optimizer**  
> 查询优化器，SQL语句在查询之前会使用查询优化器对查询进行优化
> 
> **Cache和Buffer（高速缓存区）**  
> 查询缓存，如果查询缓存有命中的查询结果，查询语句就可以直接去查询缓存中取数据
> 
> **pluggable storage Engines**  
> 插件式存储引擎。存储引擎是MySql中具体的与文件打交道的子系统
> 
> **File System**  
> 文件系统，数据、日志（redo，undo）、索引、错误日志、查询记录、慢查询等

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70]

# 二、性能与JOIN #

## 1、性能下降原因 ##

### 索引失效 ###

**单值索引**

创建语句

CREATE INDEX idx_表名_字段名 ON 表名(字段名);

**复合索引**

CREATE INDEX idx_表名_字段名1字段名2... ON 表名(字段名1, 字段名2 ...);

### 关联太多JOIN ###

*  内连接、外连接的表不要过多

### 服务器调优及参数设置 ###

## 2、SQL执行加载顺序 ##

### 手写顺序 ###

[![img][]][img 1]

随着 Mysql 版本的更新换代，其优化器也在不断的升级，优化器会分析不同执行顺序产生的性能消耗不同而**动态调整执行顺序**

下面是经常出现的查询顺序：

[![img][img 2]][img_img 2]

[![img][img 3]][img_img 3]

[![img][img 4]][img_img 4]

## 3、7种JOIN ##

[![img][img 5]][img_img 5]

### **建表语句** ###

CREATE TABLE `t_dept` (
    `id` INT(11) NOT NULL AUTO_INCREMENT, `deptName` VARCHAR(30) DEFAULT NULL, `address` VARCHAR(40) DEFAULT NULL, PRIMARY KEY (`id`)
    ) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
    CREATE TABLE `t_emp` (
    `id` INT(11) NOT NULL AUTO_INCREMENT, `name` VARCHAR(20) DEFAULT NULL, `age` INT(3) DEFAULT NULL, `deptId` INT(11) DEFAULT NULL, empno INT NOT NULL, PRIMARY KEY (`id`), KEY `idx_dept_id` (`deptId`)
    #CONSTRAINT `fk_dept_id` FOREIGN KEY (`deptId`) REFERENCES `t_dept` (`id`)
    ) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
    INSERT INTO t_dept(deptName,address) VALUES('华山','华山');
    INSERT INTO t_dept(deptName,address) VALUES('丐帮','洛阳');
    INSERT INTO t_dept(deptName,address) VALUES('峨眉','峨眉山');
    INSERT INTO t_dept(deptName,address) VALUES('武当','武当山');
    INSERT INTO t_dept(deptName,address) VALUES('明教','光明顶');
    INSERT INTO t_dept(deptName,address) VALUES('少林','少林寺');
    INSERT INTO t_emp(NAME,age,deptId,empno) VALUES('风清扬',90,1,100001);
    INSERT INTO t_emp(NAME,age,deptId,empno) VALUES('岳不群',50,1,100002);
    INSERT INTO t_emp(NAME,age,deptId,empno) VALUES('令狐冲',24,1,100003);
    INSERT INTO t_emp(NAME,age,deptId,empno) VALUES('洪七公',70,2,100004);
    INSERT INTO t_emp(NAME,age,deptId,empno) VALUES('乔峰',35,2,100005);
    INSERT INTO t_emp(NAME,age,deptId,empno) VALUES('灭绝师太',70,3,100006);
    INSERT INTO t_emp(NAME,age,deptId,empno) VALUES('周芷若',20,3,100007);
    INSERT INTO t_emp(NAME,age,deptId,empno) VALUES('张三丰',100,4,100008);
    INSERT INTO t_emp(NAME,age,deptId,empno) VALUES('张无忌',25,5,100009);
    INSERT INTO t_emp(NAME,age,deptId,empno) VALUES('韦小宝',18,NULL,100010);

### JOIN查询 ###

*  笛卡尔积

SELECT * FROM t_dept, t_emp;

t\_dept共20条记录，t\_emp共6条记录。两表共同查询后共120条记录

*  内连接

SELECT * FROM t_emp a INNER JOIN t_dept b ON  a.deptId = b.id;

[![img][img 6]][img_img 6]

查询结果为主表中所有记录，如果从表有匹配项则显示，如果从表没有匹配项则显示null。

*  左外连接 (左边为主表, 右边为从表) - 从表没有的用NULL替换

SELECT * FROM t_emp a LEFT JOIN t_dept b ON  a.deptId = b.id;

[![img][img 7]][img_img 7]

*  右外连接

SELECT * FROM t_emp a RIGHT JOIN t_dept b ON  a.deptId = b.id;

[![img][img 8]][img_img 8]

*  左外连接**取左表的独有部分**

SELECT * FROM t_emp a LEFT JOIN t_dept b ON  a.deptId = b.id WHERE a.deptId IS NULL;

[![img][img 9]][img_img 9]

*  右外连接**取右表的独有部分**

SELECT * FROM t_emp a RIGHT JOIN t_dept b ON a.deptId = b.id WHERE a.deptId IS NULL;

[![img][img 10]][img_img 10]

**注意**：判断字段是否为NULL时，**不能使用’=’**

因为

= NULL

的结果不会报错，但是**结果永远为false**。所以必须使用

IS NULL

来进行判空

*  全外连接

`MySQL不支持全外连接`，要查询两个表的全集，需要合并两个查询结果，所以要使用 **UNION** 关键字

SELECT * FROM t_emp a LEFT JOIN t_dept b ON a.deptId = b.id
    UNION
    SELECT * FROM t_emp a RIGHT JOIN t_dept b ON a.deptId = b.id;

[![img][img 11]][img_img 11]

*  查询两表独有内容

SELECT * FROM t_emp a LEFT JOIN t_dept b ON a.deptId = b.id WHERE b.id IS NULL
    UNION
    SELECT * FROM t_emp a RIGHT JOIN t_dept b ON a.deptId = b.id WHERE a.deptId IS NULL;

[![img][img 12]][img_img 12]

# 三、索引优化 #

## 1、什么是索引 ##

> 什么叫做覆盖索引？
> 
>  *  解释一 : 就是`select的数据列`只用`从索引中就能够取得`，换句话说查询列要被所使用的索引覆盖 (覆盖索引不需要回表查询)。

> 不是所有类型的索引都可以成为`覆盖索引`。覆盖索引必须要存储索引的列，而哈希索引、空间索引和全文索引等都不存储索引列的值，所以MySQL只能使用B-Tree索引做覆盖索引当发起一个被索引覆盖的查询(也叫作索引覆盖查询)时，在EXPLAIN的Extra列可以看到“Using index”的信息。
> 
>  *  注：遇到以下情况，执行计划不会选择覆盖查询。
> 
> 1.  select选择的字段中含有不在 索引 中的字段 ，即索引没有覆盖全部的列。
> 2.  where条件中不能含有对索引进行like的操作。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 1]

>  *  聚簇索引, 非聚簇索引参考上面; 非聚簇索引必须要回表查询吗? 什么是回表查询, 非聚簇索引也称为二次索引, 也称为辅助索引, 首先不是必须要回表查询的, **如果建立的索引(联合索引), 查询的列, 都是索引列, 此时就不需要回表查询; (覆盖索引)**
>  *  如果select \* 查, 此时除了索引列不需要回表查之外, 其他列都需要, 在叶子结点中根据指向聚簇索引的指针, 去聚簇索引树中进行查询数据。
>  *  有时候回表查询太多, mysql底层就不走索引, 直接就走全表扫描.

*  MySQL 官方对索引的定义为：**索引（Index）是帮助 MySQL 高效获取数据的数据结构**。可以得到索引的本质： **`索引是数据结构`**。  
    可以简单理解为：**`排好序的快速查找数据结构`**
 *  在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据， 这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。下图就是一种可能的索引方式示例：

[![img][img 13]][img_img 13]

*  左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址。为了加快 Col2 的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用 二叉查找在一定的复杂度内获取到相应数据，从而快速的检索出符合条件的记录
 *  一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上

## 2、索引的优缺点 ##

### 优点 ###

*  **提高数据检索的效率**，降低数据库的IO成本
 *  通过索引列对数据进行排序，**降低数据排序的成本**，降低了CPU的消耗

### 缺点 ###

*  虽然索引大大提高了查询速度，同时却 **`会降低更新表的速度`**，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件每次更新添加了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息
 *  实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，所以**索引列也是要占用空间的**

## 3、索引的分类 ##

### 基本语法 ###

*  创建
    
        CREATE [UNIQUE] INDEX [indexName] ON table_name(column);
 *  删除
    
        DROP INDEX [indexName] ON table_name;
 *  查看
    
        SHOW INDEX FROM table_name;

### 分类 ###

*  聚簇索引 (主键索引) – 在Innodb中 `(聚簇索引底层生成的B+树, 叶子结点存储的就是数据)`
 *  单值索引
    
     *  定义：即一个索引只包含单个列，一个表可以有多个单列索引
     *  语法：
        
            --和表一起创建
            CREATE TABLE customer (
            id INT(10) UNSIGNED AUTO_INCREMENT,
            customer_no VARCHAR(200),
            customer_name VARCHAR(200), 
            PRIMARY KEY(id), 
            KEY (customer_name) --单值索引
            );
            
            --单独创建单值索引
            CREATE INDEX idx_customer_name ON customer(customer_name);
 *  唯一索引
    
     *  定义：索引列的值必须唯一，但允许有空值
     *  语法：
        
            --和表一起创建
            CREATE TABLE customer (
            id INT(10) UNSIGNED AUTO_INCREMENT,
            customer_no VARCHAR(200),
            customer_name VARCHAR(200), 
            PRIMARY KEY(id), 
            KEY (customer_name), --单值索引
            UNIQUE (customer_no) --唯一索引
            );
            
            --单独创建唯一索引
            CREATE UNIQUE INDEX idx_customer_no ON customer(customer_no);
 *  主键索引
    
     *  定义：设定为主键后数据库会**自动建立索引**，innodb为聚簇索引
     *  语法：
        
            --和表一起创建
            CREATE TABLE customer (
            id INT(10) UNSIGNED AUTO_INCREMENT,
            customer_no VARCHAR(200),
            customer_name VARCHAR(200), 
            PRIMARY KEY(id) --主键索引
            );
            
            --单独创建主键索引
            ALTER TABLE customer ADD PRIMARY KEY customer(customer_no);
            
            --删除主键索引
            ALTER TABLE customer DROP PRIMARY KEY;
            
            --修改建主键索引
            必须先删除掉(drop)原索引，再新建(add)索引
 *  复合索引 (联合索引 / 辅助索引) --> 底层生成的B+树, 叶子结点存储的是 `符合索引key和主键索引的地址`
    
     *  定义：即一个索引包含多个列
     *  语法：
        
            --和表一起创建
            CREATE TABLE customer (
            id INT(10) UNSIGNED AUTO_INCREMENT,
            customer_no VARCHAR(200),
            customer_name VARCHAR(200), 
            PRIMARY KEY(id), 
            KEY (customer_name), --单值索引
            UNIQUE (customer_no), --唯一索引
            KEY (customer_no,customer_name) --复合索引
            );
            
            --单独创建复合索引
            CREATE INDEX idx_no_name ON customer(customer_no,customer_name);

## 4、MySQL的索引 ##

### B树与B+树 ###

*  这就是`B+树`的`叶子结点`, 它就是`InnoDB`中的`页`, 用来存放`表数据`  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 2]  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 3]

[![img][img 14]][img_img 14]

> B+树除了叶子结点, 其他结点都`存储的是key, 也就是列`也就是索引列, 它们相当于`一个指针`, 叶子结点用来存储`表中的数据`.  
> [![img][img 15]][img_img 15]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 4]

> 从上到下 —> 走索引  
> 从左到右 —> 走全表扫描  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 5]

#### 区别 ####

> [MySQL 索引底层为什么选择B+Tree][MySQL _B_Tree]

*  **B树** 的 **`关键字和记录是放在一起的`**，叶子节点可以看作外部节点，不包含任何信息；
 *  `B+树`的非叶子节点中只有关键字和指向下一个节点的索引，**`记录(表数据)只放在叶子节点中`**

**为什么说 B+树比 B-树更适合实际应用中操作系统的文件索引和数据库索引？**

*  B+树的磁盘读写代价更低
    
     *  B+树的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对 B 树更小。如果把所有同一内部结点 的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说 IO 读写次数也就降低了
 *  B+树的查询效率更加稳定
    
     *  由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当

### MySQL中的B+树 ###

> 全表扫描: 就是`直接查询B+树的叶子结点`, 不从`根节点`开始通过索引查询

#### 主键索引 ####

[![img][img 16]][img_img 16]

*  MySQL在创建表时，会根据主键来创建主键索引（如果没有主键，会用一个隐藏值来作为主键）。主键索引所构建的B+树，表中所有的记录都存放在了树的最后一层。**且与一般的B+树不同的是：叶子节点间的指针是双向的**

#### 复合索引 (辅助索引) ####

[![img][img 17]][img_img 17]

> 如果是按照查询全部列, select \* , 此时除了`查询出走索引的列`, 还需要通过`主键索引`去表中回查其他列的数据, 这个过程也叫做`回表查询`
> 
>  *  如果查询的是 select b, c, d 此时就直接走索引查询了
>  *  `最左前缀原则`, 就是通过 `B+树`节点上的索引列, 进行匹配, 看是否可以`从上到下`进行索引查找.
>  *  select \* from t\_emp where b = 1 and c = 1; 此时根据最左前缀, 是可以走索引的; 下图 1 1 \* 可以找到 1 1 1
>  *  select \* from t\_emp where c = 1 and d = 1; 此时就不可走索引; \* 1 1, 无法确定谁开头, 所以不能走索引  
>     ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 6]  
>     **`注意:` 为什么要根据最左前缀才能使索引生效?** 因为`联合索引`添加的列, 也就是索引列, 都会存储在`B+树`的非叶子结点中, 存储的结构是和创建联合索引的顺序是一致的; 如果不遵守最左前缀原则, 则想通过索引是查询不到的.

创建复合索引时，会将作为**复合索引字段的值**进行排序并放在B+树的最后一层中，同时还会将其**对应的主键值**放在其后。如：

其中字段a为主键，字段bcd共同作为复合索引，此时存放在最后一层的数据就是：111（复合索引） 2（主键索引）

**根据这个特点，可以看出复合索引具有以下使用方法**

*  最左前缀原则：使用`复合索引`的顺序必须和`创建`的**顺序一致**
 *  **覆盖索引的同时，可以带上主键字段**，如
    
        SELECT a, b, c, d FROM t_emp;
    
    因为 **`主键字段和复合索引一起存放在了复合索引说产生的B+树的最后一层`**。如果需要a字段，无需进行全表扫描
 *  如果进行范围查找，可能会进行全表扫描，这取决于处在范围内记录的多少
    
     *  **记录多**，**从复合索引映射到主键索引的次数过多(回表查询次数太多)，成本过高，会直接进行全表扫描**
        
            EXPLAIN SELECT * FROM t_emp WHERE age > 1;
        
        [![img][img 18]][img_img 18]
     *  **记录少**，先**使用复合索引**，然后映射到全表中的对应记录上
        
            EXPLAIN SELECT * FROM t_emp WHERE age > 80;
        
        [![img][img 19]][img_img 19]
     *  但是使用**覆盖索引**，无论记录多少，都会用到索引
        
            EXPLAIN SELECT age, name FROM t_emp WHERE age > 1;
        
        [![img][img 20]][img_img 20]
 *  不带WHERE也可以通过复合索引查找到主键+复合索引的记录

EXPLAIN SELECT id, age, name, deptId FROM t_emp ;

[![img][img 21]][img_img 21]

## 5、索引的使用场景 ##

### 适合索引的场景 ###

*  `主键自动建立唯一索引`
 *  频繁作为**查询条件**的字段应该创建索引
 *  查询中与其它表关联的字段，**外键关系**建立索引
 *  单键/组合索引的选择问题，**组合索引性价比更高**
 *  查询中**排序的字段**，排序字段若通过索引去访问将大大提高排序速度
 *  查询中**统计**或者**分组**字段

### 不适合索引的场景 ###

*  表**记录太少**（有无索引差别不大）
 *  经常**增删改**的表或者字段
 *  Where 条件里用不到的字段不创建索引
 *  **过滤性不好**的不适合建索引（重复性较高，比如国籍、性别之类的字段）

# 四、Explain 性能分析 #

> [不会MySQL调优？来来瞅瞅SQL的执行计划吧][MySQL_SQL]

## 1、概念 ##

*  使用 **`EXPLAIN`** 关键字可以模拟优化器执行 SQL 查询语句，从而知道 MySQL 是如何处理你的 SQL 语句的。**分析**你的查询语句或是表结构的**性能瓶颈**

## 2、用法 ##

--EXPLAIN + SQL语句，如：
    EXPLAIN SELECT * FROM person;

**Explain 执行后返回的信息：**

[![img][img 22]][img_img 22]

## 3、表头字段介绍 ##

### 准备工作 ###

CREATE TABLE t1(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
    CREATE TABLE t2(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
    CREATE TABLE t3(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
    CREATE TABLE t4(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
    INSERT INTO t1(content) VALUES(CONCAT('t1_',FLOOR(1+RAND()*1000)));
    INSERT INTO t2(content) VALUES(CONCAT('t2_',FLOOR(1+RAND()*1000)));
    INSERT INTO t3(content) VALUES(CONCAT('t3_',FLOOR(1+RAND()*1000)));
    INSERT INTO t4(content) VALUES(CONCAT('t4_',FLOOR(1+RAND()*1000)));

### id：SQL语句中表的读取顺序 ###

*  `id是select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序`
 *  **id相同**：执行顺序为 **从上至下执行**
    
        EXPLAIN SELECT * FROM t1, t2, t3 WHERE t1.id = t2.id AND t2.id = t3.id;
    
    [![img][img 23]][img_img 23]
    
    查询时，表的加载**顺序为t1, t2, t3**
 *  **id不同**：执行顺序为 **id大的先执行**
    
        EXPLAIN SELECT t2.id FROM t2 WHERE t2.id = 
        (SELECT t1.id FROM t1 WHERE t1.id = 
        (SELECT t3.id FROM t3)
        );
    
    [![img][img 24]][img_img 24]
    
    查询时，表的加载**顺序为t3, t1, t2**
 *  **id相同又不同**： 执行顺序为
    
     *  id不同时，值较大的先执行
     *  id相同时，从上至下执行
    
        EXPLAIN SELECT * FROM (SELECT t3.id FROM t3) s1, t2 WHERE s1.id = t2.id;
    
    [![img][img 25]][img_img 25]
    
    查询时，表的**加载顺序为t3, t2, 虚表dervied2**
    
     *  其中dervied**2** 的 2，为 id = 2

### select\_type：查询操作类型 ###

select\_type代表**查询的类型**，主要是用于区别**普通查询、联合查询、子查询等**的复杂查询

<table> 
 <thead> 
  <tr> 
   <th>elect_type 属性</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>SIMPLE</td> 
   <td>简单的 select 查询,查询中<strong>不包含子查询或者 UNION</strong></td> 
  </tr> 
  <tr> 
   <td>PRIMARY</td> 
   <td>查询中若包含任何复杂的子部分，<strong>最外层</strong>查询则被标记为 Primary</td> 
  </tr> 
  <tr> 
   <td>DERIVED</td> 
   <td>在 FROM 列表中包含的子查询被标记为 DERIVED(衍生) MySQL 会递归执行这些子查询, 把结果放在临时表里</td> 
  </tr> 
  <tr> 
   <td>SUBQUERY</td> 
   <td>在SELECT或WHERE列表中包含了<strong>子查询</strong></td> 
  </tr> 
  <tr> 
   <td>DEPEDENT SUBQUERY</td> 
   <td>在SELECT或WHERE列表中包含了子查询,<strong>子查询基于外层</strong></td> 
  </tr> 
  <tr> 
   <td>UNCACHEABLE SUBQUERY</td> 
   <td><strong>无法使用缓存</strong>的子查询</td> 
  </tr> 
  <tr> 
   <td>UNION</td> 
   <td>若第二个SELECT出现在UNION之后，则被标记为UNION； 若UNION包含在FROM子句的子查询中,外层SELECT将被标记为：DERIVED</td> 
  </tr> 
  <tr> 
   <td>UNION RESULT</td> 
   <td>从UNION表<strong>获取结果</strong>的SELECT</td> 
  </tr> 
 </tbody> 
</table>

*  SUBQUERY 和 DEPEDENT SUBQUERY
    
     *  都是 WHERE 后面的条件，SUBQUERY 是单个值（=），DEPEDENT SUBQUERY 是一组值（IN）
 *  UNCACHEABLE SUBQUERY
    
     *  当使用了 **@@来引用系统变量** 的时候，不会使用缓存
 *  UNION 和 UNION RESULT
    
        EXPLAIN SELECT * FROM t_emp a LEFT JOIN  t_dept b ON a.deptId = b.id WHERE b.id IS NULL
        UNION
        SELECT * FROM t_emp a RIGHT JOIN  t_dept b ON a.deptId = b.id WHERE a.deptId IS NULL;
    
    [![img][img 26]][img_img 26]

### table：表的来源 ###

*  table表示这个数据是基于哪张表的

### type：访问类型 `(重点)` ###

*  type 是查询的访问类型。**是较为重要的一个指标**，结果值从最好到最坏依次是：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > all
    
    --常见的顺序为
    system > const > eq_ref > ref > range > index > all

一般来说，得保证查询 **`至少达到 range 级别`**，最好能达到 ref

<table> 
 <thead> 
  <tr> 
   <th>类型名</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>SYSTEM</td> 
   <td>表只有一行记录（等于系统表），这是 const 类型的特列，平时不会出现，这个也<strong>可以忽略不计</strong></td> 
  </tr> 
  <tr> 
   <td>CONST</td> 
   <td>表示<strong>通过索引一次就找到了</strong>,const 用于比较 primary key 或者 unique 索引。因为只匹配一行数据，所以很快。如将主键置于 where 列表中，MySQL 就能将该查询转换为一个常量</td> 
  </tr> 
  <tr> 
   <td>EQ_REF</td> 
   <td>唯一性索引扫描，对于每个索引键，<strong>表中只有一条记录与之匹配</strong>。常见于主键或唯一索引扫描</td> 
  </tr> 
  <tr> 
   <td>REF</td> 
   <td>非唯一性索引扫描，返回匹配某个单独值的所有行。本质上也是一种索引访问，它返回所有匹配某个单独值的行， 然而，它<strong>可能会找到多个符合条件的行</strong>，所以他应该属于查找和扫描的混合体</td> 
  </tr> 
  <tr> 
   <td>RANGE</td> 
   <td>只检索给定<strong>范围</strong>的行,使用一个索引来选择行。key 列显示使用了哪个索引一般就是在你的 where 语句中出现 了 between、&lt;、&gt;、in 等的查询这种范围扫描索引扫描比全表扫描要好，因为它只需要开始于索引的某一点，而 结束语另一点，不用扫描全部索引</td> 
  </tr> 
  <tr> 
   <td>INDEX</td> 
   <td>出现index是sql使用了索引但是没用通过索引进行过滤，一般是使用了覆盖索引或者是利用索引进行了排序分组</td> 
  </tr> 
  <tr> 
   <td>ALL</td> 
   <td>Full Table Scan，将遍历全表以找到匹配的行</td> 
  </tr> 
 </tbody> 
</table>

*  REF
    
        --其中deptId为索引，且用到了' = '
        EXPLAIN SELECT * FROM t_emp WHERE deptId = 3;
    
    [![img][img 27]][img_img 27]
 *  RANGE
    
        --其中deptId为索引，用到了 BETWEEN...AND... , IN , > , < 等范围查询
        EXPLAIN SELECT * FROM t_emp WHERE deptId > 3;
    
    [![img][img 28]][img_img 28]
 *  INDEX

-- 使用了覆盖索引
      --其中deptId为索引，查找了整张表时，用到了索引
      EXPLAIN SELECT deptId FROM t_emp;

[![img][img 29]][img_img 29]

*  ALL
    
        --其中name为非索引
        EXPLAIN SELECT name FROM t_emp;
    
    [![img][img 30]][img_img 30]

### possible\_key：可能用到的索引 ###

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

### key：实际使用的索引 ###

*  **实际使用的索引**。如果为NULL，则没有使用索引

EXPLAIN SELECT * FROM t_emp WHERE id = 1 AND deptId = 1;

[![img][img 31]][img_img 31]

MySQL推测可能用到`主键索引`和`idx_dept_id`索引，实际上用到的是`主键索引`

#### **覆盖索引** ####

*  当`查找的字段`与`建立的索引的匹配`（查询的字段都是索引，但不需要全是索引）时，会发生覆盖索引。MySQL推测使用的索引为NULL，而实际上会使用索引

有以下两种解释

*  select的数据列**只用从索引中就能够取得**，不必从数据表中读取，换句话说**查询列要被所使用的索引覆盖**
 *  索引是高效找到行的一个方法，当能通过检索索引就可以读取想要的数据，那就不需要再到数据表中读取行了。如果一个索引包含了（或覆盖了）满足查询语句中字段与条件的数据就叫做覆盖索引

注意：要使用覆盖索引，则**只取出需要的列**（被令为索引），**不要**使用 `SELECT *`

--其中id和deptId都为索引
    EXPLAIN SELECT id, deptId FROM t_emp;

[![img][img 32]][img_img 32]

[![img][img 33]][img_img 33]

### key\_len：索引使用字节数 ###

> 根据`列修饰的类型`计算, 比如 int类型占4个字节

*  表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。 key\_len 字段能够帮你检查是否充分的利用上了索引
 *  **`ken_len 越长，说明索引使用的越充分`**

### ref：显示被使用的索引的具体信息 ###

*  ref显示索引的哪一列被使用了，如果可能的话，可以是一个常数。哪些列或常量被用于查找索引列上的值

EXPLAIN SELECT * FROM t_dept, t_emp WHERE t_emp.deptId = t_dept.id;

[![img][img 34]][img_img 34]

### rows：被查询的行数 ###

*  rows 列显示 MySQL 认为它执行查询时必须检查的行数。**越少越好！**

**验证**

--先删除索引
    DROP INDEX idx_dept_id ON t_emp;
    
    --查找
    EXPLAIN SELECT * FROM t_dept, t_emp WHERE t_emp.deptId = t_dept.id;
    
    --再创建索引
    CREATE INDEX idx_dept_id ON t_emp(deptId);
    
    --查找
    EXPLAIN SELECT * FROM t_dept, t_emp WHERE t_emp.deptId = t_dept.id;

**结果如下**

*  **未使用索引时，一共需要查询26行**
    
    [![img][img 35]][img_img 35]
 *  **使用索引后，一共需要查询6行**
    
    [![img][img 36]][img_img 36]

### Extra：额外重要信息 ###

其他的额外**重要**的信息

*  **Using filesort**：`使用外部索引排序`（未使用用户创建的索引）
    
    > 解决: 查询的时候按照`最左前缀原则`查询;
    
     *  说明 mysql 会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。MySQL 中无法利用索引 完成的排序操作称为“文件排序”
     *  出现 Using filesort **说明SQL语句设计的不好**，**没有按照创建的索引进行排序**，或者**未按照索引指定的顺序进行排序**
    
    **演示**
    
        --创建符合索引
        CREATE INDEX idx_emp_empno_age ON t_emp(empno, age);
        
        --进行查询操作，通过 age 字段进行排序（未按照复合索引顺序进行排序查询）
        EXPLAIN SELECT empno FROM t_emp WHERE empno >100002 ORDER BY age;
        
        --进行查询操作，通过 empno 或者 empno + age 字段进行排序（按照复合索引顺序进行排序查询）
        EXPLAIN SELECT empno FROM t_emp WHERE empno >100002 ORDER BY empno;
        EXPLAIN SELECT empno FROM t_emp WHERE empno >100002 ORDER BY empno, age;
    
    **结果**
    
    [![img][img 37]][img_img 37]
    
    [![img][img 38]][img_img 38]
    
    [![img][img 39]][img_img 39]
 *  **Using temporary**

> 造成的原因: order by / group by ; 在联合索引的情况下, 未按照最左前缀访问索引列

*  使了用`临时表`保存中间结果,MySQL 在对查询结果排序时使用临时表。**`常见于排序 order by 和分组查询 group by`**
 *  出现 Using temporary **说明SQL语句设计的非常不好**，可能是因为没有按照顺序使用复合索引

**演示**

--进行查询操作， 通过 age 字段进行分组（未按照复合索引顺序进行排序查询）
    CREATE INDEX idx_emp_empno_age ON t_emp(empno, age);
    
    ----进行查询操作，通过 empno 或者 empno + age 字段进行分组（按照复合索引顺序进行排序查询）
    EXPLAIN SELECT empno FROM t_emp WHERE empno >100002 GROUP BY empno;
    EXPLAIN SELECT empno FROM t_emp WHERE empno >100002 GROUP BY empno, age;

**结果**

[![img][img 40]][img_img 40]

[![img][img 41]][img_img 41]

**重要结论**

**`注意:`** 如果创建了**复合索引**，一定要**按照复合索引的顺序来使用 (最左前缀原则)**，否则会使得性能大幅下降

*  **Using index**
    
     *  `Using index` 代表表示相应的 select 操作中使用了 **`覆盖索引`** (Covering Index)，详见[key：实际用到的索引——覆盖索引][key]，避免访问了表的数据行，**效率不错**！
     *  如果同时出现 using where，表明**索引被用来执行索引键值的查找**
     *  如果没有同时出现 using where，表明**索引只是用来读取数据**而非利用索引执行查找。
    
    **演示**
    
        --查询 age 字段，使用了WHERE
        EXPLAIN SELECT age FROM t_emp WHERE age >100000;
        
        --查询 empno 和 age 字段，未使用WHERE
        EXPLAIN SELECT empno, age FROM t_emp;
        
        --查询 empno 和 name 字段 （name字段不是索引）
        EXPLAIN SELECT empno, name FROM t_emp;
    
    **结果**
    
    [![img][img 42]][img_img 42]
    
    [![img][img 43]][img_img 43]
    
    [![img][img 44]][img_img 44]
 *  Using where
    
     *  表明使用了 where 过滤
 *  Using join buffer
    
     *  使用了连接缓存
 *  impossible where
    
     *  where 子句的值总是 false，不能用来获取任何元组
 *  select tables optimized away
    
     *  在没有 GROUP BY 子句的情况下，基于索引优化 MIN/MAX 操作或者对于 MyISAM 存储引擎优化 COUNT(\*)操 作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化

# 五、单表查询优化 #

## 1、全值匹配很快捷 ##

**SQL语句**

--建立符合索引（age, deptId, name）
    CREATE INDEX idx_emp_ade ON t_emp(age, deptId, NAME);
    
    --查找
    EXPLAIN SELECT empno FROM t_emp WHERE age = 90;
    EXPLAIN SELECT empno FROM t_emp WHERE age = 90 AND deptId = 1;
    EXPLAIN SELECT empno FROM t_emp WHERE age = 90 AND deptId = 1 AND name = '风清扬';
    
    --和上一条SQL语句中WHERE后字段的顺序不同，但是不影响查询结果
    EXPLAIN SELECT empno FROM t_emp WHERE deptId = 1 AND name = '风清扬' AND age = 90;

**对应结果**

[![img][img 45]][img_img 45]

[![img][img 46]][img_img 46]

[![img][img 47]][img_img 47]

[![img][img 48]][img_img 48]

可以看到，**复合索引都被用到了，并且SQL中查询字段的顺序，跟使用索引中字段的顺序，没有关系**。优化器会在不影响 SQL 执行结果的前提下，自动地优化

**结论：`全职匹配我最爱指的是，查询的字段按照顺序在索引中都可以匹配到`**

## 2、最佳左前缀法则 ##

**SQL语句**

--先删除之前创建的单值索引
    DROP INDEX idx_dept_id ON t_emp; 
    
    --查询，未按照最佳左前缀法则
    EXPLAIN SELECT empno FROM t_emp WHERE deptId = 1;
    EXPLAIN SELECT empno FROM t_emp WHERE deptId = 1 AND name = '风清扬';
    
    --查询，部分按照最佳左前缀法则（age字段和复合索引匹配，但name没有）
    EXPLAIN SELECT empno FROM t_emp WHERE  age = 90 AND name = '风清扬';
    
    --查询，完全按照最佳左前缀法则
    EXPLAIN SELECT empno FROM t_emp WHERE age = 90 AND deptId = 1;
    EXPLAIN SELECT empno FROM t_emp WHERE age = 90 AND deptId = 1 AND name = '风清扬';

**对应结果**

[![img][img 49]][img_img 49]

[![img][img 50]][img_img 50]

[![img][img 51]][img_img 51]

[![img][img 46]][img_img 46]

[![img][img 48]][img_img 48]

*  可以看到，查询 **`字段与索引字段顺序的不同会导致，索引无法充分使用，甚至索引失效`**

**原因**：使用复合索引，需要**遵循最佳左前缀法则**，即如果索引了多列，要遵守最左前缀法则。指的是查询从索引的**最左前列开始并且不跳过索引中的列**

**结论：过滤条件要使用索引必须按照索引建立时的顺序，依次满足，`一旦跳过某个字段，索引后面的字段都无法被使用`**

## 3、索引列上进行 (计算、函数、(自动 or 手动)类型转换), 索引失效 ##

*  不在索引列上做任何操作（计算、函数、(自动 or 手动)类型转换），**可能会导致索引失效而转向全表扫描**

**SQL语句**

--直接查询
    EXPLAIN SELECT empno FROM t_emp WHERE age = 90 AND deptId = 1 AND NAME = '风清扬';
    
    --使用MySQL函数查询
    EXPLAIN SELECT empno FROM t_emp WHERE LEFT(age,2) = 90 AND deptId = 1 AND name = '风清扬';

**对应结果**

[![img][img 52]][img_img 52]

[![img][img 53]][img_img 53]

可以看出，当age字段使用了left函数以后，**导致索引完全失效**

**结论：等号左边无计算**

## 4、范围之后全失效 ##

**SQL语句**

--范围查询
    EXPLAIN SELECT empno FROM t_emp WHERE age > 50 AND deptId = 1 AND name = '风清扬';
    EXPLAIN SELECT empno FROM t_emp WHERE age = 50 AND deptId > 1 AND NAME = '风清扬';
    
    --未使用范围查询
    EXPLAIN SELECT empno FROM t_emp WHERE age = 50 AND deptId = 1 AND name = '风清扬';

**对应结果**

[![img][img 54]][img_img 54]

[![img][img 55]][img_img 55]

[![img][img 56]][img_img 56]

可以看出，当对age字段使用范围查询后，使得范围后面的索引失效了

**建议：将可能做范围查询的字段的索引顺序放在最后**

**结论：使用范围查询后，如果范围内的记录过多，会导致索引失效**，因为从自定义索引映射到主键索引需要耗费太多的时间，反而不如全表扫描来得快

## 5、覆盖索引多使用 ##

**SQL语句**

--查询所有字段
    EXPLAIN SELECT * FROM t_dept WHERE id = 1;
    
    --查询索引字段
    EXPLAIN SELECT id FROM t_dept WHERE id = 1;

**对应结果**

[![img][img 57]][img_img 57]

[![img][img 58]][img_img 58]

**结论：使用覆盖索引（Using index）会提高检索效率**

## 6、使用不等会失效 ##

在使用**不等于(!= 或者<>)时**，有时会无法使用索引会导致全表扫描

**SQL语句**

--SQL语句中有不等于
    EXPLAIN SELECT * FROM t_emp WHERE age != 90;
    EXPLAIN SELECT * FROM t_emp WHERE age <> 90;
    
    --SQL语句中没有不等于
    EXPLAIN SELECT * FROM t_emp WHERE age = 90;

**对应结果**

[![img][img 59]][img_img 59]

[![img][img 60]][img_img 60]

[![img][img 61]][img_img 61]

**`结论：尽量不要使用不等于`**

## 7、使用NULL值要小心 ##

在使用

IS NULL
    或者
    IS NOT

时，可能会导致索引失效

但是如果**允许字段为空**，则

*  IS NULL 不会导致索引失效
 *  IS NOT NULL 会导致索引失效

[![img][img 62]][img_img 62]

**SQL语句**

EXPLAIN SELECT * FROM t_emp WHERE age IS NULL;
    
    EXPLAIN SELECT * FROM t_emp WHERE age IS NOT NULL;

**对应结果**

[![img][img 63]][img_img 63]

[![img][img 64]][img_img 64]

## 8、模糊查询加右边 ##

要使用模糊查询时，**百分号最好加在右边，而且进行模糊查询的字段必须是单值索引**

**SQL语句**

--创建单值索引
    CREATE INDEX idx_emp_name ON t_emp(NAME);
    
    --进行模糊查询
    EXPLAIN SELECT * FROM t_emp WHERE name LIKE '%风';
    EXPLAIN SELECT * FROM t_emp WHERE name LIKE '风%';
    EXPLAIN SELECT * FROM t_emp WHERE name LIKE '%风%';

**对应结果**

[![img][img 65]][img_img 65]

[![img][img 66]][img_img 66]

[![img][img 65]][img_img 65]

可以看出，对索引使用模糊查询时，**只有当百分号在右边，索引为单值索引且模糊查询语句在最右边时，索引才会生效**

其他情况均失效了

**但是**有时必须使用其他类型的模糊查询，这时就需要用**覆盖索引**来解决索引失效的问题

**SQL语句**

EXPLAIN SELECT name FROM t_emp WHERE name LIKE '%风';
    EXPLAIN SELECT name FROM t_emp WHERE name LIKE '风%';
    
    EXPLAIN SELECT NAME FROM t_emp WHERE name LIKE '%风%';

**对应结果**

[![img][img 67]][img_img 67]

[![img][img 68]][img_img 68]

[![img][img 67]][img_img 67]

**结论：对索引进行模糊查询时，最好在右边加百分号。必须在左边或左右加百分号时，需要用到覆盖索引来提升查询效率**

## 9、字符串加单引号 ##

当字段为字符串时，查询时必须带上单引号。否则**会发生自动的类型转换**，从而发生全表扫描

**用于查询的表**

[![img][img 69]][img_img 69]

**其中card\_id字段为varchar类型，且设置了单值索引**

**SQL语句**

--使用了单引号
    EXPLAIN SELECT card_id FROM person WHERE card_id = '1';
    
    --未使用单引号，发生自动类型转换
    EXPLAIN SELECT card_id FROM person WHERE card_id = 1;

**对应结果**

[![img][img 70]][img_img 70]

[![img][img 71]][img_img 71]

## 10、尽量不用or查询 ##

如果使用or，可能导致索引失效。所以要减少or的使用，可以**使用 union all 或者 union 来替代：**

**SQL语句**

--使用or进行查询
    EXPLAIN SELECT * FROM t_emp WHERE age = 90 OR NAME = '风清扬';

**对应结果**

[![img][img 72]][img_img 72]

## 口诀 ##

*  **全职匹配我最爱，最左前缀要遵守  
    带头大哥不能死，中间兄弟不能断  
    索引列上少计算，范围之后全失效  
    LIKE 百分写最右，覆盖索引不写  
    不等空值还有 OR，索引影响要注意  
    VARCHAR 引号不可丢，SQL 优化有诀窍**

# 六、关联查询优化 #

**建表语句**

CREATE TABLE IF NOT EXISTS `class` (
    `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT, `card` INT(10) UNSIGNED NOT NULL, PRIMARY KEY (`id`)
    );
    CREATE TABLE IF NOT EXISTS `book` (
    `bookid` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT, `card` INT(10) UNSIGNED NOT NULL, PRIMARY KEY (`bookid`)
    );
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
    INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));

## 1、LEFT JOIN优化 ##

**SQL语句**

--未建立索引时的左外连接查询
    EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;
    
    --左表（class）建立索引
    CREATE INDEX idx_class_card ON class(card);
    
    --再次执行查询
    EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;
    
    --去掉左表索引
    DROP INDEX idx_class_card ON class;
    
    --右表建立索引
    CREATE INDEX idx_book_card ON book(card);
    
    --再次执行查询
    EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;

**对应结果**

[![img][img 73]][img_img 73]

[![img][img 74]][img_img 74]

[![img][img 75]][img_img 75]

**结论**

*  在优化关联查询时，只有在 **`被驱动表上建立索引才有效`**
 *  `left join`时，左侧的为驱动表，**右侧为被驱动表**

## 2、INNER JOIN优化 ##

**SQL语句**

--查询操作，目前索引在book表的card上，class表和book表的位置不会改变查询结果
    EXPLAIN SELECT * FROM class INNER JOIN book ON class.card = book.card;
    EXPLAIN SELECT * FROM book INNER JOIN class ON book.card = class.card;
    
    --删除book表中的几条记录
    DELETE FROM book WHERE bookid<10;
    
    --再次查询
    EXPLAIN SELECT * FROM class INNER JOIN book ON class.card = book.card;
    
    --删除book表card字段索引，给class表的card字段添加索引
    DROP INDEX idx_book_card ON book;
    CREATE INDEX idx_class_card ON class(card);
    
    --再次查询
    EXPLAIN SELECT * FROM class INNER JOIN book ON class.card = book.card;

**对应结果**

[![img][img 76]][img_img 76]

[![img][img 77]][img_img 77]

[![img][img 78]][img_img 78]

**结论**：

*  inner join 时，**mysql 会把小结果集的表选为驱动表**（小表驱动大表）
 *  **所以最好把索引建立在大表（数据较多的表）上**

## 3、RIGHT JOIN优化 ##

优化类型和LEFT JOIN类似，只不过**被驱动表变成了左表**

# 七、排序分组优化 #

*  在查询中难免会对查询结果进行排序操作。进行排序操作时要 **`避免出现 Using filesort`**，应使**用索引给排序带来的方便**

**索引信息**

[![img][img 79]][img_img 79]

## 1、ORDER BY 优化 ##

以下查询都是在 **`索引覆盖`** 的条件下进行的

**SQL语句**

--不满足索引覆盖时进行排序查询
    EXPLAIN SELECT empno FROM t_emp  WHERE age > 50 ORDER BY age, deptId;
    
    --按照复合索引顺序进行排序
    EXPLAIN SELECT age, deptId FROM t_emp  WHERE age > 50 ORDER BY age;
    EXPLAIN SELECT age, deptId FROM t_emp  WHERE age > 50 ORDER BY age, deptId;
    EXPLAIN SELECT age, deptId FROM t_emp  WHERE age > 50 ORDER BY age, deptId, name;
    
    --不按照复合索引顺序进行排序（无 age 字段），发生Using filesort
    EXPLAIN SELECT age, deptId FROM t_emp  WHERE age > 50 ORDER BY deptId, name;
    
    --不按照复合索引顺序进行排序（索引顺序打乱），发生Using filesort
    EXPLAIN SELECT age, deptId FROM t_emp  WHERE age > 50 ORDER BY deptId, name, age;
    
    --排序时部分(age)升序，部分(deptId)降序，发生Using filesort
    EXPLAIN SELECT age, deptId FROM t_emp  WHERE age > 50 ORDER BY age ASC, deptId DESC;
    
    --排序时都为降序
    EXPLAIN SELECT age, deptId FROM t_emp  WHERE age > 50 ORDER BY age DESC, deptId DESC;
    
    --排序时，在前面的字段为常量时（非范围）
    EXPLAIN SELECT age, deptId FROM t_emp  WHERE age = 50 ORDER BY deptId, name;
    EXPLAIN SELECT age, deptId FROM t_emp  WHERE age = 50 AND deptId>10000 ORDER BY deptId, name;

**对应结果**

[![img][img 80]][img_img 80]

[![img][img 81]][img_img 81]

[![img][img 82]][img_img 82]

[![img][img 83]][img_img 83]

[![img][img 84]][img_img 84]

[![img][img 85]][img_img 85]

[![img][img 86]][img_img 86]

[![img][img 87]][img_img 87]

**结论**：

要想在排序时使用索引，避免 Using filesort，首先需要发生**索引覆盖**，其次

*  **ORDER BY 后面字段的顺序** 要和`复合索引`的**顺序完全一致**
 *  ORDER BY 后面的索引必须按照顺序出现，**排在后面的可以不出现**
 *  要进行升序或者降序时，**字段的排序顺序必须一致**。不能一部分升序，一部分降序，可以都升序或者都降序
 *  如果复合索引前面的**字段作为常量**出现在过滤条件中，**排序字段可以为紧跟其后的字段**

### MySQL的排序算法 ###

当发生 Using filesort 时，MySQL会根据自己的算法对查询结果进行排序

*  双路排序
    
     *  MySQL 4.1 之前是使用双路排序,字面意思就是**两次扫描磁盘**，最终得到数据，读取行指针和 order by 列，对他们进行排序，然后扫描已经排序好的列表，按照列表中的值重新从列表中读取对应的数据输出
     *  从磁盘取排序字段，在 buffer 进行排序，再从磁盘取其他字段
     *  简单来说，**取一批数据，要对磁盘进行了两次扫描**，众所周知，I\\O 是很耗时的，所以在 mysql4.1 之后，出现了第二种改进的算法，就是单路排序
 *  单路排序
    
     *  从磁盘读取查询需要的所有列，按照 order by 列**在 buffer 对它们进行排序**，然后扫描排序后的列表进行输出， 它的效率更快一些，避免了第二次读取数据。并且把随机 IO 变成了顺序 IO,但是它会使用更多的空间， 因为它把每一行都保存在内存中了
     *  **存在的问题**：在 sort\_buffer 中，方法 B 比方法 A 要多占用很多空间，因为方法 B 是把所有字段都取出, 所以有可能**取出的数据的总大小超出了 sort\_buffer 的容量**，导致每次只能取 sort\_buffer 容量大小的数据，进行排序（创建 tmp 文件，多 路合并），排完再取取 sort\_buffer 容量大小，再排……从而多次 I/O。也就是**本来想省一次 I/O 操作，反而导致了大量的 I/O 操作，反而得不偿失**
 *  优化Using filesort
    
     *  增大 sort\_butter\_size 参数的设置
        
         *  不管用哪种算法，提高这个参数都会提高效率，当然，要根据系统的能力去提高，因为这个参数是针对**每个进程的 1M-8M 之间调整**
     *  增大 max\_length\_for\_sort\_data 参数的设置
        
         *  mysql 使用单路排序的前提是**排序的字段大小要小于 max\_length\_for\_sort\_data**
         *  提高这个参数，会增加用改进算法的概率。但是如果设的太高，数据总容量超出 sort\_buffer\_size 的概率就增大， 明显症状是高的磁盘 I/O 活动和低的处理器使用率。（1024-8192 之间调整）
     *  减少 select 后面的查询的字段
        
         *  查询的字段减少了，缓冲里就能容纳更多的内容了，**间接增大了sort\_buffer\_size**

[![img][img 88]][img_img 88]

## 2、GROUP BY 优化 ##

*  优化方式和 ORDER BY 类似，参考ORDER BY 的优化方式即可

# 八、截取查询分析 #

## 1、`慢日志查询` ##

> 通过慢查询日志, 将超过10s执行的sql, 收集起来. 这些就是慢sql
> 
>  *  拿到这些sql后, 我们可以再通过`explain`来分析sql, 达到优化sql的目的

### 概念 ###

*  MySQL的`慢查询日志`是MySQL提供的一种日志记录，**`它用来记录在MySQL中响应时间超过阀值的语句`**，具体指运行时间超过 **`long_query_time`** 值的SQL，则会被记录到慢查询日志中
 *  具体指运行时间超过long\_query\_time值的SQL，则会被记录到慢查询日志中。**long\_query\_time的默认值为 10**，意思是运行10秒以上的语句
 *  由他来查看哪些SQL超出了我们的最大忍耐时间值，比如一条sql执行超过5秒钟，我们就算慢SQL，希望能 收集超过5秒的sql，结合之前`explain`进行全面分析

### 使用 ###

*  默认情况下，`MySQL 数据库没有开启慢查询日志，需要我们手动来设置这个参数`
 *  如果不是调优需要的话，**`一般不建议启动该参数`**，因为**开启慢查询日志会或多或少带来一定的性能影响**。 慢查询日志支持将日志记录写入文件

<table> 
 <thead> 
  <tr> 
   <th>SQL 语句</th> 
   <th>描述</th> 
   <th>备注</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>SHOW VARIABLES LIKE ‘%slow_query_log%’</td> 
   <td>查看慢查询日志是否开启</td> 
   <td>默认情况下 slow_query_log 的值为 OFF</td> 
  </tr> 
  <tr> 
   <td>set global slow_query_log=1</td> 
   <td>开启慢查询日志</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>SHOW VARIABLES LIKE ‘long_query_time%’</td> 
   <td>查看慢查询设定阈值</td> 
   <td>单位：秒</td> 
  </tr> 
  <tr> 
   <td>set long_query_time=1</td> 
   <td>设定慢查询阈值</td> 
   <td>单位：秒</td> 
  </tr> 
 </tbody> 
</table>

*  运行查询时间长的 sql，**可以打开慢查询日志查看**

# 九、MySQL锁机制 #

> [InnoDB 事务与锁的前世今生][InnoDB]

## 1、表锁 ##

*  **MylSAM引擎使用表锁，并且不支持事务**

**SQL语句**

--展示表是否加锁
    SHOW OPEN TABLES;
    
    --加锁 read (读锁) write (写锁)
    LOCK TABLE table1 read(write), table2 read(write)...
    
    --全部解锁
    UNLOCK TABLES;

### 读锁 ###

*  主机A给表加上 **表锁（读锁）** 以后
    
     *  主机A和其他主机都可以读取**该表**的信息
     *  **主机A不能读取库中其他表的信息**，但其他主机可以读取库中所有表的信息
     *  如果要修改被锁表的信息
        
         *  主机A如果对表进行修改，**会修改失败**
         *  其他主机对表进行修改，**会被阻塞，直到锁被释放**

**演示**

*  给dept表加锁并查询状态
    
        LOCK TABLE dept READ;
        
        SHOW OPEN TABLES;
    
    [![img][img 89]][img_img 89]

**读取**

*  两个客户端分别读取dept表的信息，都能读出来
    
        SELECT id FROM dept WHERE id = 1;
 *  客户端A（加锁端）A**读取其他表**信息，**读取失败**
    
        SELECT * FROM t_emp;
    
    [![img][img 90]][img_img 90]
 *  其他客户端读取度其他表信息，读取成功
    
        SELECT * FROM t_emp;
    
    [![img][img 91]][img_img 91]

**修改**

*  客户端A对表中内容进行修改，**修改失败**
    
        DELETE FROM dept WHERE id = 1;
    
    [![img][img 92]][img_img 92]
 *  客户端B对表中内容进行修改，进入阻塞状态
    
        DELETE FROM dept WHERE id = 1;

[![img][img 93]][img_img 93]

*  从客户端A解锁后，客户端B修改成功
    
        UNLOCK TABLES;
    
    [![img][img 94]][img_img 94]

### 写锁 ###

主机A给表加上 **表锁（写锁）** 以后

*  主机A可以读取该表信息，但**其他主机读取时，会进入阻塞状态，知道读锁被释放**
 *  **主机A不能读取库中其他表的信息**，但其他主机可以读取库中**除该表以外所有表**的信息
 *  如果要修改被锁表的信息
    
     *  主机A如果对表进行修改，修改成功
     *  其他主机对表进行修改，**会被阻塞，直到锁被释放**

**演示**

*  给dept表加上写锁并查看
    
        LOCK TABLE dept WRITE;
        
        SHOW OPEN TABLES;
    
    [![img][img 95]][img_img 95]

**读取**

*  客户端A查询该表内容，查询成功；读取其他表，读取失败
    
        SELECT * FROM dept;
        
        SELECT * FROM t_emp;
    
    [![img][img 96]][img_img 96]

[![img][img 97]][img_img 97]

*  其他表读取该表信息，进入阻塞状态
    
        SELECT * FROM dept;
    
    [![img][img 98]][img_img 98]
 *  释放后，读取成功
    
        UNLOCK TABLES;

**修改**

*  客户端A修改**该表**内容，修改成功
    
        DELETE dept WHERE id = 2;
    
    [![img][img 99]][img_img 99]
 *  客户端A修改**其他表**内容，修改失败
    
        DELETE FROM t_emp WHERE id = 2;
    
    [![img][img 100]][img_img 100]
 *  其他客户端修改**该表**内容，进入阻塞状态
    
        DELETE FROM t_emp WHERE id = 2;

### 总结 ###

**读锁不会阻塞读，只会阻塞写。但是写锁会阻塞读和写。**

## 2、行锁 ##

**InnoDB使用行锁，并且支持事务**，事务相关可参考 [**MySQL基础**][MySQL 1]

### 特点 ###

如果两个客户端**对同一条记录进行修改**

*  客户端A修改后，未提交（未commit），此时客户端B修改，则会阻塞
 *  客户端A修改后，提交后，客户端B再修改，则不会阻塞

如果两个客户端分别**对不同的记录进行修改**，则不会被阻塞

**修改同一条记录**

--关闭自动提交
    SET autocommit = 0;
    
    --客户端A、B查询id=2的记录
    SELECT * FROM t_emp WHERE id = 2;
    
    --客户端A进行修改操作（将年龄改为了80），但未提交
    UPDATE t_emp SET age = 80 WHERE id = 2;
    
    --客户端A进行查询
    SELECT * FROM t_emp WHERE id = 2;
    
    --客户端B进行查询
    SELECT * FROM t_emp WHERE id = 2;
    
    --客户端B进行修改（客户端A未提交）
    UPDATE t_emp SET age = 90 WHERE id = 2;
    
    --客户端A提交
    COMMIT;
    
    --客户端B提交
    COMMIT;

**对应结果**

客户端A查询结果

[![img][img 101]][img_img 101]

客户端B查询结果

[![img][img 101]][img_img 101]

客户端A修改后A查询

[![img][img 102]][img_img 102]

客户端A修改后B查询

[![img][img 101]][img_img 101]

客户端A修改，未提交，此时B进行修改，**被阻塞**

[![img][img 103]][img_img 103]

客户端A提交后，B修改成功

[![img][img 104]][img_img 104]

**修改不同记录**

--客户端A对id=2的年龄进行修改
    UPDATE t_emp SET age = 90 WHERE id = 2;
    
    --客户端B对id=3的年龄进行修改
    UPDATE t_emp SET age = 30 WHERE id = 3;
    
    --客户端A，B分别提交
    COMMIT;
    COMMIT;

因为InnoDB使用行锁，对于不同行的操作，不会出现阻塞现象

### 索引失效 ###

索引失效，**行锁变表锁**

当**索引失效**后，即使多个客户端操作的不是同一条记录，**如果未提交，其他客户端也会进入阻塞状态**

所以要**避免索引失效**

### 间隙锁危害 ###

#### 概念 ####

当我们用**范围条件**而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁

对于键值**在条件范围内但并不存在的记录**，叫做\*\*“间隙(GAP)\*\*” ，**InnoDB也会对这个“间隙”加锁**，这种锁机制就是所谓的间隙锁(Next-Key锁)。

#### 危害 ####

因为Query执行过程中通过过范围查找的话，他会锁定整个范围内所有的索引键值，即使这个键值并不存在。  
间隙锁有一个比较致命的弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无  
法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害

#### 演示 ####

--查询表记录，此处没有id=2的记录
    SELECT * FROM t_emp;
    
    --客户端A进行范围查询，但是范围内没有id=2的记录
    UPDATE t_emp SET deptId = 1 WHERE id>1 AND id < 6;
    
    --客户端B进行插入数据，插入一条id=2的记录
    INSERT t_emp VALUES(2, '岳不群', 11, 2, 100002); 
    
    --客户端A提交
    COMMIT;
    
    --客户端B提交
    COMMIT;

[![img][img 105]][img_img 105]

**客户端B进入阻塞状态**

[![img][img 106]][img_img 106]

提交后，插入成功

[![img][img 107]][img_img 107]

**结论**：可以看到表中本来**没有id=2的记录**，但是在客户端A进行**范围修改**时，客户端B对**在范围内但不存在的数据进行插入时，客户端B进入了阻塞状态**

### 锁住指定的一行 ###

BEGIN;
    
    --锁住指定的一行，如果进行更新操作就是 ... FOR UPDATE，删除操作就是 ... FOR DELETE 以此类推
    SELECT * FROM t_emp WHERE id = 1 FOR UPDATE;
    
    --进行修改操作
    UPDATE t_emp SET NAME = '风车车' WHERE id = 1;
    
    --提交
    COMMIT;

如果当某一行被锁住后，其他客户端对改行进行操作，会被**阻塞**

### 总结 ###

Innodb存储引擎由于实现了**行级锁定**，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些， 但是在整体**并**  
**发处理能力方面要远远优于MyISAM的表级锁定的**。当系统并发量较高的时候，Innodb的整体性能和MyISAM相比就会有比较明显的  
优势了。  
但是，Innodb的行级锁定同样也有其脆弱的一面，当我们**使用不当的时候**，可能会让Innodb的整体性能表现不仅不能比MylSAM高  
，甚至可能会更差。

# 十、复制 #

## 1、主从复制 ##

主要涉及三个线程：binlog 线程、I/O 线程和 SQL 线程。

*  **binlog 线程** ：负责将主服务器上的数据更改**写入二进制日志**（Binary log）中。
 *  **I/O 线程** ：负责从主服务器上读取二进制日志，并**写入从服务器的中继日志**（Relay log）。
 *  **SQL 线程** ：负责**读取中继日志**，解析出主服务器已经执行的数据更改并在从服务器中重放（Replay）。

[![img][img 108]][img_img 108]

## 2、读写分离 ##

**主服务器处理写操作**以及实时性要求比较高的读操作，而**从服务器处理读操作**

读写分离能提高性能的原因在于：

*  主从服务器负责各自的读和写，极大程度**缓解了锁的争用**
 *  **从服务器**可以使用 [MyISAM][]，提升查询性能以及节约系统开销
 *  增加冗余，提高可用性

读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器

[![img][img 109]][img_img 109]

[Nyima_MySQL]: https://nyimac.gitee.io/2020/08/13/MySQL%E9%AB%98%E7%BA%A7/
[MySQL]: https://blog.csdn.net/lzb348110175/article/details/106553867
[SQL_MySQL]: https://blog.csdn.net/lzb348110175/article/details/106647986
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x6YjM0ODExMDE3NQ_size_16_color_FFFFFF_t_70]: /images/20221119/0027ae140d014c1388f618ed479e92d1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70]: /images/20221119/0ece2f27c210447496b2bcdb472bf58a.png
[img]: /images/20221119/b018008a31f5433ab9335b843a9f8916.png
[img 1]: https://nyimapicture.oss-cn-beijing.aliyuncs.com/img/20200814112248.png
[img 2]: https://img-blog.csdnimg.cn/img_convert/8726580c6c089cf5cbc2756badb33492.png
[img_img 2]: /images/20221119/435e7c1ee15c42cb810c39b902dfe62d.png
[img 3]: https://img-blog.csdnimg.cn/img_convert/246991777b170198a723ec7e3af4e57f.png
[img_img 3]: /images/20221119/11ac1562a54b412a9795d11c4212fb87.png
[img 4]: https://img-blog.csdnimg.cn/img_convert/12e09f4b053ef071efde5df37b26a11e.png
[img_img 4]: /images/20221119/7dc4dc93930f4460ae401df98edb16a3.png
[img 5]: https://img-blog.csdnimg.cn/img_convert/d012f4da9e416696562eb64cbc96b0ee.png
[img_img 5]: /images/20221119/622b25c0124b45eaa6394004517b5bb0.png
[img 6]: https://img-blog.csdnimg.cn/img_convert/827b11693e714527d876d756419d4c67.png
[img_img 6]: /images/20221119/1a7e3eb5be424b7fa9535120790dbc03.png
[img 7]: https://img-blog.csdnimg.cn/img_convert/e20aacb14a2fb6cc29ec01b02a153eb4.png
[img_img 7]: /images/20221119/0a8f51163f994d3bb01d2ca58595cde6.png
[img 8]: https://img-blog.csdnimg.cn/img_convert/d3168d5fe6e6680a938a3fa330c26769.png
[img_img 8]: /images/20221119/740d333947d642a780b4f269b960eae5.png
[img 9]: https://img-blog.csdnimg.cn/img_convert/fd828f23ad4bcf0da14cb46d0efc1415.png
[img_img 9]: /images/20221119/969abe3dff944408a82478ba53c3b96c.png
[img 10]: https://img-blog.csdnimg.cn/img_convert/91692279b7a9a2bcf4af461922c79689.png
[img_img 10]: /images/20221119/e6b2db77e6b14eabac268f9f29cb57a6.png
[img 11]: https://img-blog.csdnimg.cn/img_convert/04c9524d4d3aad85a16c18b33396e8cd.png
[img_img 11]: /images/20221119/9b8e89e8f70c47b698a78cf48a486bf8.png
[img 12]: https://img-blog.csdnimg.cn/img_convert/522e9e28779fedc553e5317b54334048.png
[img_img 12]: /images/20221119/89a5d8ff1da74b149da9803cd02d9074.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 1]: /images/20221119/08de71b852cd4b6d9f9b04541aea333b.png
[img 13]: https://img-blog.csdnimg.cn/img_convert/7ddb71de21ad389c8199f29e72c30826.png
[img_img 13]: /images/20221119/de452628caa34c28b2a71b1f7359b699.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 2]: /images/20221119/41b8a133f5524f91a819b813668ecc32.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 3]: /images/20221119/ccc50be8cedb48bdb4aab5b516403c9f.png
[img 14]: https://img-blog.csdnimg.cn/img_convert/e832f470915d4b3d7c5b030bd8d1c5f2.png
[img_img 14]: /images/20221119/0db92ea978b04992b4f9b87024a5d365.png
[img 15]: https://img-blog.csdnimg.cn/img_convert/67dc6e4867577cd640da37b220418e1c.png
[img_img 15]: /images/20221119/1f036cff4b52410b8af9e5f54ab54157.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 4]: /images/20221119/ff60ad3dd10a49bd8676c070a33f94c5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 5]: /images/20221119/2020dd6b96cc4b7f9ee9a1ab518e1992.png
[MySQL _B_Tree]: https://blog.csdn.net/lzb348110175/article/details/103999658
[img 16]: https://img-blog.csdnimg.cn/img_convert/9b6c0ba127b2bfcb745fc44f462da5c6.png
[img_img 16]: /images/20221119/65e2e251d5f04545a765119e00d1db7d.png
[img 17]: https://img-blog.csdnimg.cn/img_convert/f486edd11e2bb98a0096c5724931d9c7.png
[img_img 17]: /images/20221119/acb51cf7d8a24a11834412cabcb1e098.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 6]: /images/20221119/5cc93b7914c34dd48b4e134d867efbb3.png
[img 18]: https://img-blog.csdnimg.cn/img_convert/e9407f65f8c22011e5d2e888b5a12521.png
[img_img 18]: /images/20221119/1c78e1fcfa604e65b1bd0f474e8b6c49.png
[img 19]: https://img-blog.csdnimg.cn/img_convert/43ad15033f72dd570fe1c1e3e74e432d.png
[img_img 19]: /images/20221119/d723a6cfb3744b4994fca0c8eb2b72fb.png
[img 20]: https://img-blog.csdnimg.cn/img_convert/6a982a135dbdb1732be7039e2c582f77.png
[img_img 20]: /images/20221119/080fb69887fc480bb784b7c168bfe0f9.png
[img 21]: https://img-blog.csdnimg.cn/img_convert/07d6612084ae9bf97905f4da70329fc1.png
[img_img 21]: /images/20221119/fca5521aea5b45eebbe0df975a67dc8f.png
[MySQL_SQL]: https://blog.csdn.net/lzb348110175/article/details/106665860
[img 22]: https://img-blog.csdnimg.cn/img_convert/12d33a5d834d64c5a84f0b977f562840.png
[img_img 22]: /images/20221119/ba22adf9716f4919a3a3d29b014b95b4.png
[img 23]: https://img-blog.csdnimg.cn/img_convert/885f381dac5339b219223ba54fb6f5a5.png
[img_img 23]: /images/20221119/20e42e8b2fa740539e3c3fefa9d279c1.png
[img 24]: https://img-blog.csdnimg.cn/img_convert/caab73ed5b7ed5f4f5e5097384ddb176.png
[img_img 24]: /images/20221119/c42d638a5d9c494eaffd814da525dd63.png
[img 25]: https://img-blog.csdnimg.cn/img_convert/92d99676e8993c2e9bdef36cbabffbb0.png
[img_img 25]: /images/20221119/31363b3d1c00492eb1a432a3403774a6.png
[img 26]: https://img-blog.csdnimg.cn/img_convert/b4601874d705432e98b244c82ded02f1.png
[img_img 26]: /images/20221119/1b9321e457a84209a9f24ee8f9105bc6.png
[img 27]: https://img-blog.csdnimg.cn/img_convert/f100fb821da7b74cebbeb7a971113a09.png
[img_img 27]: /images/20221119/be8f99f15b7f49cdb868e6a5d57a9083.png
[img 28]: https://img-blog.csdnimg.cn/img_convert/ac1bd68da859f728b8608005075e1d44.png
[img_img 28]: /images/20221119/5393661e4e4543c1bdbc9ff30545170c.png
[img 29]: https://img-blog.csdnimg.cn/img_convert/f517349ebf67c5044de3f0682b31e88c.png
[img_img 29]: /images/20221119/39d60dd3cbc64b778c12badc7cc24989.png
[img 30]: https://img-blog.csdnimg.cn/img_convert/4ca9dc73bf68e383ead5382c5a532943.png
[img_img 30]: /images/20221119/193e443c887d4591a0ac98577a4f4100.png
[img 31]: https://img-blog.csdnimg.cn/img_convert/7e756b34197c035f76b9170c9bc4a1d7.png
[img_img 31]: /images/20221119/31375bc33011467e9b55b2e0913d55e2.png
[img 32]: https://img-blog.csdnimg.cn/img_convert/eef4d5fb9fe1380bfdd7369d160508fc.png
[img_img 32]: /images/20221119/d8e4a545f1114511a227bd6a049689d6.png
[img 33]: https://img-blog.csdnimg.cn/img_convert/0fb2cdc1a536e1820847e016ee1b58d4.png
[img_img 33]: /images/20221119/d1b79068dfa2426c97eaa9fe6024fa03.png
[img 34]: https://img-blog.csdnimg.cn/img_convert/ef67c732116b493db4d1bc9fd49a6d4f.png
[img_img 34]: /images/20221119/c5810d1e180c4f2d8a241ecd6af6bf1b.png
[img 35]: https://img-blog.csdnimg.cn/img_convert/71135f86ea105b6df52362c9182a3a30.png
[img_img 35]: /images/20221119/f14eb0f1dfd74d39b3cd723f91b325cd.png
[img 36]: https://img-blog.csdnimg.cn/img_convert/9ccb9d7d7a1fb0398265d65fc1d3dd38.png
[img_img 36]: /images/20221119/f6041da77cab4d0f82b31be3a5ade83f.png
[img 37]: https://img-blog.csdnimg.cn/img_convert/dc61e775fe2d61a12a1642bac4e4fa3c.png
[img_img 37]: /images/20221119/3b78069c06a94953997292cd9f04c8cc.png
[img 38]: https://img-blog.csdnimg.cn/img_convert/f600fcf764d956e55a3306ee21c99f4e.png
[img_img 38]: /images/20221119/6400ef8420864cb29a5c2dd296c00540.png
[img 39]: https://img-blog.csdnimg.cn/img_convert/92719eea5eeab2cb70cafe7ec20ab52e.png
[img_img 39]: /images/20221119/952aff96c55f4806ba2f689942e1aba1.png
[img 40]: https://img-blog.csdnimg.cn/img_convert/b9ebd52d1357b86e2c0b68fe8972892f.png
[img_img 40]: /images/20221119/a415b4e0977347c2bb7d5b2506812e71.png
[img 41]: https://img-blog.csdnimg.cn/img_convert/b88930fe19aa3a26deb6b2e789565b8d.png
[img_img 41]: /images/20221119/0d280541eea344be84f8a3c55eeb4601.png
[key]: https://nyimac.gitee.io/2020/08/16/MySQL%E9%AB%98%E7%BA%A7/#%E8%A6%86%E7%9B%96%E7%B4%A2%E5%BC%95
[img 42]: https://img-blog.csdnimg.cn/img_convert/f1a98e3ad5868b5cbf8bf90a3d10647d.png
[img_img 42]: /images/20221119/c4eba945f730485ab54827fdeda8f4b1.png
[img 43]: https://img-blog.csdnimg.cn/img_convert/4975d0152a0fe153ba2ccfdbbd1c65ec.png
[img_img 43]: /images/20221119/5ea536891deb443da42bff98e79cc2f9.png
[img 44]: https://img-blog.csdnimg.cn/img_convert/84c423e931a5474a2ce41291daec3c79.png
[img_img 44]: /images/20221119/a10058d09cd5452fb4e1169402d2144e.png
[img 45]: https://img-blog.csdnimg.cn/img_convert/bbedf619393e4f70fa15cca1fac6e931.png
[img_img 45]: /images/20221119/71668c37e13a4985b77ed9141d52e3c1.png
[img 46]: https://img-blog.csdnimg.cn/img_convert/f449f68655a50c5514cd4f6863c486b5.png
[img_img 46]: /images/20221119/2320434c6c0d43698bcf353619f1ff20.png
[img 47]: https://img-blog.csdnimg.cn/img_convert/1c1d173f94ca7395745e01d490043752.png
[img_img 47]: /images/20221119/0c33a3ce0eaf43afa7d4c358848bc6f8.png
[img 48]: https://img-blog.csdnimg.cn/img_convert/261f23af56d7e6a6364238081e7dee16.png
[img_img 48]: /images/20221119/4f06aa1b7aa142a7a122b88c55b93203.png
[img 49]: https://img-blog.csdnimg.cn/img_convert/3ea060147bce16e9aa0d57032dd618f5.png
[img_img 49]: /images/20221119/a57918c69e81478ca6cffe76385d657d.png
[img 50]: https://img-blog.csdnimg.cn/img_convert/fa68abf9e5dec5ad4b50798e9b036f5b.png
[img_img 50]: /images/20221119/6c9975ffed13408ba865e9a068a36c4f.png
[img 51]: https://img-blog.csdnimg.cn/img_convert/be1c564dfa5f2cb353be36aa74a61ef8.png
[img_img 51]: /images/20221119/593db02fcdb0479b9b2fd157a40024de.png
[img 52]: https://img-blog.csdnimg.cn/img_convert/51cca471c8340fb3ec8c5526b0053248.png
[img_img 52]: /images/20221119/dd0b5bfe9f6c41cd99cfafdf96323036.png
[img 53]: https://img-blog.csdnimg.cn/img_convert/c0f824e31727f05646a5e8df2775fcdf.png
[img_img 53]: /images/20221119/76ab177a40254f76b0ca0c382e0fb97f.png
[img 54]: https://img-blog.csdnimg.cn/img_convert/3527fd6e2b1b4ca5819f064a5ebfe246.png
[img_img 54]: /images/20221119/aaa6229552444681a296f860c245cb02.png
[img 55]: https://img-blog.csdnimg.cn/img_convert/bb6d001e39894829783aee5e89aee3d4.png
[img_img 55]: /images/20221119/c9f49e946f894a40a58a3987f64f198f.png
[img 56]: https://img-blog.csdnimg.cn/img_convert/bdbdb68b3709fab09390844e76b1a9a3.png
[img_img 56]: /images/20221119/1ea96efbbbec4f8db29e82da39950c86.png
[img 57]: https://img-blog.csdnimg.cn/img_convert/2571a2dcffc892fb3b287bcd59a4e59c.png
[img_img 57]: /images/20221119/f782f6a6ba224b18948fcb9b8280eb7e.png
[img 58]: https://img-blog.csdnimg.cn/img_convert/e5e92bdd1e69456d83b3e0ff83166fe7.png
[img_img 58]: /images/20221119/c52e41e5a3ee48569eef77cc8592a221.png
[img 59]: https://img-blog.csdnimg.cn/img_convert/b4a9c8cae54e9b91bbb2f063c0c54d43.png
[img_img 59]: /images/20221119/4d7a9e764dd8452e9fee97d84b12dd1c.png
[img 60]: https://img-blog.csdnimg.cn/img_convert/1b55fc72c48a743de5c69c78e3acab08.png
[img_img 60]: /images/20221119/a522885c456b4a298fa3f06ed8a046cc.png
[img 61]: https://img-blog.csdnimg.cn/img_convert/104cdd6464d1efa132fcc8a3febd41c7.png
[img_img 61]: /images/20221119/e29b8923695646e2992ae161f1701965.png
[img 62]: https://img-blog.csdnimg.cn/img_convert/ed88ac31d2f6927f1f3b122223e44439.png
[img_img 62]: /images/20221119/59dde0c61f564b0798f21992c3096b8d.png
[img 63]: https://img-blog.csdnimg.cn/img_convert/575b5be54a1807812e54885033175f39.png
[img_img 63]: /images/20221119/3690d66801834955839df65043ab4795.png
[img 64]: https://img-blog.csdnimg.cn/img_convert/17e6bc2a971c0d093f155b13916eceef.png
[img_img 64]: /images/20221119/abc42bf990c54568882e9000b6168c6e.png
[img 65]: https://img-blog.csdnimg.cn/img_convert/af8dcae61ab19c488484447f4137318a.png
[img_img 65]: /images/20221119/33c5a2d945ec451da9a5eea5792d040a.png
[img 66]: https://img-blog.csdnimg.cn/img_convert/514239ca18d222ec402a2b2842f40d73.png
[img_img 66]: /images/20221119/87b8645786154eef807278fd146362bc.png
[img 67]: https://img-blog.csdnimg.cn/img_convert/74c26f5976b16f82d49909378886ed81.png
[img_img 67]: /images/20221119/12f206d77ec948ec97a0d06ce7b12d03.png
[img 68]: https://img-blog.csdnimg.cn/img_convert/fddbb9078ccd78d5c493fb18d5912c8e.png
[img_img 68]: /images/20221119/7f20a09ecd48497d8cfcef92d4140fdd.png
[img 69]: https://img-blog.csdnimg.cn/img_convert/fd42cdbcdc0b5318abcbb74062356efc.png
[img_img 69]: /images/20221119/bff19e64f85046c4996e3066be6f7c67.png
[img 70]: https://img-blog.csdnimg.cn/img_convert/c51f4132f8eb446723a7658b0d292f10.png
[img_img 70]: /images/20221119/e40263d1b7d94b059499abcaa547e89a.png
[img 71]: https://img-blog.csdnimg.cn/img_convert/91c19c4cd8f5fbee174a4c1352409566.png
[img_img 71]: /images/20221119/52ea8053b83e47bf8ddcd48e9b7278db.png
[img 72]: https://img-blog.csdnimg.cn/img_convert/64b8a6a0ccde0a86c8282d145cc1fed5.png
[img_img 72]: /images/20221119/562f23a72b4b44209581161d68a2a60e.png
[img 73]: https://img-blog.csdnimg.cn/img_convert/01f66ce0481bd8b30881312fd38a8738.png
[img_img 73]: /images/20221119/87f33d449d474a35a085e12eda95f70e.png
[img 74]: https://img-blog.csdnimg.cn/img_convert/bd124a54c8f1e22d94d4fb2611436ba5.png
[img_img 74]: /images/20221119/82f4c59819d2452a9385813748065b1f.png
[img 75]: https://img-blog.csdnimg.cn/img_convert/a460e25e2af2c7c8c8c988fd0ce3253b.png
[img_img 75]: /images/20221119/0673af4802cb4fadbceeeaf9d6bade84.png
[img 76]: https://img-blog.csdnimg.cn/img_convert/4d1621e7611ec64a67dc26e18436eaba.png
[img_img 76]: /images/20221119/2a8f9c77c5534f259cf00cecf2a20145.png
[img 77]: https://img-blog.csdnimg.cn/img_convert/f9082d4a32f2f8608f0ee895154b830e.png
[img_img 77]: /images/20221119/3c7e7bc9fd9c484684c100e10f7573f5.png
[img 78]: https://img-blog.csdnimg.cn/img_convert/562d72cc8c0eae34d561a63ed8d5a782.png
[img_img 78]: /images/20221119/12b29c395f2c4d5eb3a0d748a4817317.png
[img 79]: https://img-blog.csdnimg.cn/img_convert/c6ca09458f10331bbd3d66ac69c50ec5.png
[img_img 79]: /images/20221119/c523a0b907a74ab1a7dae15ae46ef1a9.png
[img 80]: https://img-blog.csdnimg.cn/img_convert/375977e821ebd8e2c849a1309312ad20.png
[img_img 80]: /images/20221119/cd48ad75f7374624ae1f964316c89c6f.png
[img 81]: https://img-blog.csdnimg.cn/img_convert/403ea4d48b6511a4bd91f5533284500f.png
[img_img 81]: /images/20221119/8cf0795b90bd4178944db86349834afa.png
[img 82]: https://img-blog.csdnimg.cn/img_convert/b94669ea646691bbc616dfd529cdb628.png
[img_img 82]: /images/20221119/66c940381fc54a22a533a27d0058c3d2.png
[img 83]: https://img-blog.csdnimg.cn/img_convert/d5849b239fdbb60195ef7e9f9bbb973c.png
[img_img 83]: /images/20221119/91a078aa0edf47e48c6d92ef249d4c3e.png
[img 84]: https://img-blog.csdnimg.cn/img_convert/77765c0c27e7018be6cbe273445b96bb.png
[img_img 84]: /images/20221119/ce3208c54f614abfaa843c7f17d171ae.png
[img 85]: https://img-blog.csdnimg.cn/img_convert/f4854910e5a88fe64a633f8de1a0cd85.png
[img_img 85]: /images/20221119/e72138aa1fba4a58890faa4d4ec9af70.png
[img 86]: https://img-blog.csdnimg.cn/img_convert/83c56d39158bfbcced36f8b6b7b88a64.png
[img_img 86]: /images/20221119/3d07ac9802814fbd9c03db822fb85575.png
[img 87]: https://img-blog.csdnimg.cn/img_convert/e29919dfcb9fb7076a50b2cb4d750cb6.png
[img_img 87]: /images/20221119/2828de0b99734144aa7b5c3832cf7c68.png
[img 88]: https://img-blog.csdnimg.cn/img_convert/3a719fd73f74eb7734e676bc250fa46c.png
[img_img 88]: /images/20221119/b87fe92acaf3465cb40a685989e49c13.png
[InnoDB]: https://blog.csdn.net/m0_37989980/article/details/112254502
[img 89]: https://img-blog.csdnimg.cn/img_convert/e710d5d4aa3ecc18cdbb8f37c4373566.png
[img_img 89]: /images/20221119/4f18be9e0bdb4b9cb9a6e45b111e415d.png
[img 90]: https://img-blog.csdnimg.cn/img_convert/08c3cd729bca5dabd96a10e66537512e.png
[img_img 90]: /images/20221119/74ade758d54b41af9b16b33f92fc3ba5.png
[img 91]: https://img-blog.csdnimg.cn/img_convert/b91d4a9ae0c0413662d73db274291ab0.png
[img_img 91]: /images/20221119/9680f162bc4542c4aed65b03f050f6a0.png
[img 92]: https://img-blog.csdnimg.cn/img_convert/b2abefafb3c0b7fbd19d6fc14b0f9c31.png
[img_img 92]: /images/20221119/6c89fc8f1e8347069d8040234d6147ec.png
[img 93]: https://img-blog.csdnimg.cn/img_convert/66aad97c693f852acd13024f685ed0f1.png
[img_img 93]: /images/20221119/bae654786f0040b08190d102bf12cb1f.png
[img 94]: https://img-blog.csdnimg.cn/img_convert/4b8a534d62742a1ce5bbbd1d46a07272.png
[img_img 94]: /images/20221119/dcbde6ee50474225b50898fbf82d1266.png
[img 95]: https://img-blog.csdnimg.cn/img_convert/d6aabc3b67f3a3ea14c2ce7bbf8c3b9a.png
[img_img 95]: /images/20221119/c706824150524da098027aea8132dedc.png
[img 96]: https://img-blog.csdnimg.cn/img_convert/36d88cbd4783e4397da357193f7002fe.png
[img_img 96]: /images/20221119/fd44a31469f349d5a601e9d79f58e602.png
[img 97]: https://img-blog.csdnimg.cn/img_convert/003d1255c56d1f6fb8ae430cba16f5b9.png
[img_img 97]: /images/20221119/eaa4b3a7a4fa4d2fbfc36cc901278d82.png
[img 98]: https://img-blog.csdnimg.cn/img_convert/4a8a3a0633e1a97fe3f553a427c4a21b.png
[img_img 98]: /images/20221119/c0c60cfcadce4d8bb4dfb1cf1a3099d3.png
[img 99]: https://img-blog.csdnimg.cn/img_convert/7f98d4b23519136a24ef6b2a91ab3004.png
[img_img 99]: /images/20221119/c98fb4801e1f4486826bd24a6dbcba47.png
[img 100]: https://img-blog.csdnimg.cn/img_convert/cbec63aee8c9b9e132144cef140ebdeb.png
[img_img 100]: /images/20221119/a1e4144831754969a543f8ba0eeb4a47.png
[MySQL 1]: https://nyimac.gitee.io/2020/08/11/MySQL%E5%9F%BA%E7%A1%80/#%E5%85%AD%E3%80%81%E4%BA%8B%E5%8A%A1
[img 101]: https://img-blog.csdnimg.cn/img_convert/e6260302c68abc3d4c8e463c49c3b640.png
[img_img 101]: /images/20221119/19daf60b2fed41609429e166e8440754.png
[img 102]: https://img-blog.csdnimg.cn/img_convert/f3e8773062ab46ba9f8b1dffdc2a67d5.png
[img_img 102]: /images/20221119/6808919bf14b4f598036722ab9f39ef9.png
[img 103]: https://img-blog.csdnimg.cn/img_convert/417a2ea885b82bebcea5314b8259305e.png
[img_img 103]: /images/20221119/a6e3d81b152f49e38ab5f6d2ae784e2b.png
[img 104]: https://img-blog.csdnimg.cn/img_convert/e87774722dbc30b36406a5f945ae0e51.png
[img_img 104]: /images/20221119/fa2a9859129347bbae76849c9df64127.png
[img 105]: https://img-blog.csdnimg.cn/img_convert/3858eb4125ac36c01acdf1ecb945fb54.png
[img_img 105]: /images/20221119/d62cce218200430eb857f8b2f19ed268.png
[img 106]: https://img-blog.csdnimg.cn/img_convert/b6ba0b9479038f4971b876ae691fae66.png
[img_img 106]: /images/20221119/e9e6dab98807429298fd6ace5892c752.png
[img 107]: https://img-blog.csdnimg.cn/img_convert/b7b01948382ffa3ac3d01e6772e628d5.png
[img_img 107]: /images/20221119/e0132bab3da94b0a97fde9d25983abf1.png
[img 108]: https://img-blog.csdnimg.cn/img_convert/987ea905a364f90fef3bcd483e77b34a.png
[img_img 108]: /images/20221119/f99fc9307b2e476285a41726cb0db29a.png
[MyISAM]: https://nyimac.gitee.io/2020/08/16/MySQL%E9%AB%98%E7%BA%A7/#%E5%BC%95%E6%93%8E%E5%B1%82
[img 109]: https://img-blog.csdnimg.cn/img_convert/a45ca5a17f29f244be4eee7fa5a6fd0f.png
[img_img 109]: /images/20221119/4c30126f190142d1ac756bcc482c6dfc.png