MySQL之sql优化

分手后的思念是犯贱 2023-07-24 09:06 3阅读 0赞

### sql优化 ###

*  1 sql优化步骤
 *   *  1.1 查看SQL执行频率
     *  1.2 定位低效率执行SQL
     *  1.3 explain分析执行计划
     *  1.4 show profile分析SQL
     *  1.5 trace分析优化器执行计划
 *  2 SQL优化
 *   *  2.1 大批量插入数据
     *  2.2 优化insert语句
     *  2.3 优化order by语句
     *   *  2.3.1两种排序方式
         *  2.3.2 Filesort 的优化
     *  2.4 优化group by 语句
     *  2.5 优化嵌套查询
     *  2.6 优化OR条件
     *  2.7 优化分页查询
     *   *  2.7.1 优化思路一
         *  2.7.2 优化思路二
     *  2.8 8 使用SQL提示
     *   *  2.8.1 USE INDEX
         *  2.8.2 IGNORE INDEX
         *  2.8.3 FORCE INDEX

# 1 sql优化步骤 #

## 1.1 查看SQL执行频率 ##

MySQL 客户端连接成功后，通过 show \[session|global\] status 命令可以提供服务器状态信息。show\[session|global\] status 可以根据需要加上参数“session”或者“global”来显示 session 级（当前连接）的计结果和global 级（自数据库上次启动至今）的统计结果。如果不写，默认使用参数是“session”。  
下面的命令显示了当前 session 中所有统计参数的值：

show status like 'Com_______';

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70]  
查看当前 session 中针对InnoDB 存储引擎所有统计参数的值：

show status like 'Innodb_rows_%';

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

*  Com\_\*\*\* : 这些参数对于所有存储引擎的表操作都会进行累计。
 *  Innodb\_\*\*\* : 这几个参数只是针对InnoDB 存储引擎的，累加的算法也略有不同。

## 1.2 定位低效率执行SQL ##

*  慢查询日志 : 通过慢查询日志定位那些执行效率较低的 SQL 语句，用–log-slow-queries\[=file\_name\]选项启动时，mysqld 写一个包含所有执行时间超过 long\_query\_time 秒的 SQL 语句的日志文件。
 *  show processlist : 慢查询日志在查询结束以后才纪录，所以在应用反映执行效率出现问题的时候查询慢查询日志并不能定位问题，可以使用show processlist命令查看当前MySQL在进行的线程，包括线程的状态、是否锁表等，可以实时地查看 SQL 的执行情况，同时对一些锁表操作进行优化。  
    ![在这里插入图片描述][20200410173928881.png]

1） id列，用户登录mysql时，系统分配的"connection_id"，可以使用函数connection_id()查看 
    2） user列，显示当前用户。如果不是root，这个命令就只显示用户权限范围的sql语句
    3） host列，显示这个语句是从哪个ip的哪个端口上发的，可以用来跟踪出现问题语句的用户 
    4） db列，显示这个进程目前连接的是哪个数据库
    5） command列，显示当前连接的执行的命令，一般取值为休眠（sleep），查询（query），连接 （connect）等 
    6） time列，显示这个状态持续的时间，单位是秒 
    7） state列，显示使用当前连接的sql语句的状态，很重要的列。state描述的是语句执行中的某一个状态。
    一个sql语句，以查询为例，可能需要经过copying to tmp table、sorting result、sending data等状态 才可以完成 
    8） info列，显示这个sql语句，是判断问题语句的一个重要依据

## 1.3 explain分析执行计划 ##

通过以上步骤查询到效率低的 SQL 语句后，可以通过 EXPLAIN或者 DESC命令获取 MySQL如何执行 SELECT 语句的信息，包括在 SELECT 语句执行过程中表如何连接和连接的顺序。  
查询SQL语句的执行计划 ：

explain select * from tb_item where id = 1;

![在这里插入图片描述][20200410174657890.png]

explain select * from tb_item where title = '阿尔卡特 (OT-979) 冰川白 联通3G手机3';

![在这里插入图片描述][20200410174739929.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 2]

## 1.4 show profile分析SQL ##

Mysql从5.0.37版本开始增加了对 show profiles 和 show profile 语句的支持。show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。  
通过 have\_profiling 参数，能够看到当前MySQL是否支持profile：

select @@have_profiling; //是否支持profile

![在这里插入图片描述][20200410175030257.png]  
默认profiling是关闭的，可以通过set语句在Session级别开启profiling：  
![在这里插入图片描述][20200410175134957.png]

set profiling=1; //开启profiling 开关；

通过profile，我们能够更清楚地了解SQL执行的过程。  
首先，我们可以执行一系列的操作，如下图所示：

show databases; use db01; 
    show tables;
    select * from tb_item where id < 5; 
    select count(*) from tb_item;

执行完上述命令之后，再执行show profiles 指令， 来查看SQL语句执行的耗时：  
![在这里插入图片描述][20200410180227451.png]  
通过show profile for query query\_id 语句可以查看到该SQL执行过程中每个线程的状态和消耗的时间：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 3]  
在获取到最消耗时间的线程状态后，MySQL支持进一步选择all、cpu、block io 、context switch、page faults等明细类型类查看MySQL在使用什么资源上耗费了过高的时间。例如，选择查看CPU的耗费时间 ：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 4]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 5]

## 1.5 trace分析优化器执行计划 ##

MySQL5.6提供了对SQL的跟踪trace, 通过trace文件能够进一步了解为什么优化器选择A计划, 而不是选择B计划。  
打开trace ， 设置格式为 JSON，并设置trace最大能够使用的内存大小，避免解析过程中因为默认内存过小而不能够完整展示。

SET optimizer_trace="enabled=on",end_markers_in_json=on; 
    set optimizer_trace_max_mem_size=1000000;

执行SQL语句 ：

select * from tb_item where id < 4;

最后， 检查information\_schema.optimizer\_trace就可以知道MySQL是如何执行SQL的 ：

select * from information_schema.optimizer_trace\G;

# 2 SQL优化 #

## 2.1 大批量插入数据 ##

当使用load 命令导入数据的时候，适当的设置可以提高导入的效率。

对于 InnoDB 类型的表，有以下几种方式可以提高导入的效率：  
**1） 主键顺序插入**  
因为InnoDB类型的表是按照主键的顺序保存的，所以将导入的数据按照主键的顺序排列，可以有效的提高导入数据的效率。如果InnoDB表没有主键，那么系统会自动默认创建一个内部列作为主键，所以如果可以给表创建一个主键，将可以利用这点，来提高导入数据的效率。

**2）关闭唯一性校验**  
在导入数据前执行 SET UNIQUE\_CHECKS=0，关闭唯一性校验，在导入结束后执行SET UNIQUE\_CHECKS=1，恢复唯一性校验，可以提高导入的效率。

SET UNIQUE_CHECKS=0 #关闭唯一性校验
      SET UNIQUE_CHECKS=1 #恢复唯一性校验

**3） 手动提交事务**  
如果应用使用自动提交的方式，建议在导入前执行 SET AUTOCOMMIT=0，关闭自动提交，导入结束后再执行 SETAUTOCOMMIT=1，打开自动提交，也可以提高导入的效率。

# 关闭自动提交
    SET AUTOCOMMIT=0;
    # 打开自动提交
    SET AUTOCOMMIT=1;

## 2.2 优化insert语句 ##

当进行数据的insert操作的时候，可以考虑采用以下几种优化方案。  
**（1）如果需要同时对一张表插入很多行数据时，应该尽量使用多个值表的insert语句**  
这种方式将大大的缩减客户端与数据库之间的连接、关闭等消耗。使得效率比分开执行的单个insert语句快。  
示例， 原始方式为：

insert into tb_test values(1,'Tom');
    insert into tb_test values(2,'Cat');
    insert into tb_test values(3,'Jerry');

优化后的方案为 ：

insert into tb_test values(1,'Tom'),(2,'Cat')，(3,'Jerry');

**（2）在事务中进行数据插入**

start transaction; # 开启事务
    insert into tb_test values(1,'Tom');
    insert into tb_test values(2,'Cat'); 
    insert into tb_test values(3,'Jerry'); 
    commit;# 提交事务

**（3）数据有序插入**

insert into tb_test values(4,'Tim'); 
    insert into tb_test values(1,'Tom'); 
    insert into tb_test values(3,'Jerry'); 
    insert into tb_test values(5,'Rose'); 
    insert into tb_test values(2,'Cat');

优化后

insert into tb_test values(1,'Tom'); 
    insert into tb_test values(2,'Cat'); 
    insert into tb_test values(3,'Jerry'); 
    insert into tb_test values(4,'Tim'); 
    insert into tb_test values(5,'Rose');

## 2.3 优化order by语句 ##

### 2.3.1两种排序方式 ###

1). 第一种是通过对返回数据进行排序，也就是通常说的 filesort 排序，所有不是通过索引直接返回排序结果的排序都叫 FileSort 排序。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 6]  
2). 第二种通过有序索引顺序扫描直接返回有序数据，这种情况即为 using index，不需要额外排序，操作效率高。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 7]  
多字段排序  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 8]  
了解了MySQL的排序方式，优化目标就清晰了：

*  尽量减少额外的排序，通过索引直接返回有序数据。
 *  where 条件和Order by 使用相同的索引
 *  Order By 的顺序和索引顺序相同， 并且Order by 的字段都是升序，或者都是降序。否则肯定需要额外的操作，这样就会出现FileSort。

### 2.3.2 Filesort 的优化 ###

通过创建合适的索引，能够减少 Filesort 的出现，但是在某些情况下，条件限制不能让Filesort消失，那就需要加快 Filesort的排序操作。对于Filesort ， MySQL 有两种排序算法：  
1） 两次扫描算法 ：MySQL4.1 之前，使用该方式排序。首先根据条件取出排序字段和行指针信息，然后在排序区sort buffer 中排序，如果sort buffer不够，则在临时表 temporary table 中存储排序结果。完成排序之后，再根据行指针回表读取记录，该操作可能会导致大量随机I/O操作。  
2）一次扫描算法：一次性取出满足条件的所有字段，然后在排序区 sort buffer 中排序后直接输出结果集。排序时内存开销较大，但是排序效率比两次扫描算法要高。

MySQL 通过比较系统变量 max\_length\_for\_sort\_data 的大小和Query语句取出的字段总大小， 来判定适合那种排序算法，如果max\_length\_for\_sort\_data 更大，那么使用第二种优化之后的算法；否则使用第一种。  
可以适当提高 sort\_buffer\_size 和 max\_length\_for\_sort\_data 系统变量，来增大排序区的大小，提高排序的效率。

## 2.4 优化group by 语句 ##

由于GROUP BY 实际上也同样会进行排序操作，而且与ORDER BY 相比，GROUP BY 主要只是多了排序之后的分组操作。当然，如果在分组的时候还使用了其他的一些聚合函数，那么还需要一些聚合函数的计算。所以，在GROUP BY 的实现过程中，与 ORDER BY 一样也可以利用到索引。  
如果查询包含 group by 但是用户想要避免排序结果的消耗， 则可以执行order by null 禁止排序。如下 ：

drop index idx_emp_age_salary on emp; 
    explain select age,count(*) from emp group by age;

优化后

explain select age,count(*) from emp group by age order by null;

从上面的例子可以看出，第一个SQL语句需要进行"filesort"，而第二个SQL由于order by null 不需要进行"filesort"， 而上文提过Filesort往往非常耗费时间。

## 2.5 优化嵌套查询 ##

Mysql4.1版本之后，开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，子查询是可以被更高效的连接（JOIN）替代。  
示例 ，查找有角色的所有的用户信息 :

explain select * from t_user where id in (select user_id from user_role );

执行计划为 :  
![在这里插入图片描述][20200410212844173.png]  
优化后 :

explain select * from t_user u , user_role ur where u.id = ur.user_id;

![在这里插入图片描述][20200410212936739.png]  
连接(Join)查询之所以更有效率一些 ，是因为MySQL不需要在内存中创建临时表来完成这个逻辑上需要两个步骤的查询工作。

## 2.6 优化OR条件 ##

（1）对于包含OR的查询子句，如果要利用索引，则OR之间的每个条件列都必须用到索引 ， 而且不能使用到复合索引； 如果没有索引，则应该考虑增加索引。  
（2）建议使用 union 替换 or

## 2.7 优化分页查询 ##

一般分页查询时，通过创建覆盖索引能够比较好地提高性能。一个常见又非常头疼的问题就是 limit 2000000,10 ，此时需要MySQL排序前2000010 记录，仅仅返回2000000 - 2000010 的记录，其他记录丢弃，查询排序的代价非常大 。

### 2.7.1 优化思路一 ###

在索引上完成排序分页操作，最后根据主键关联回原表查询所需要的其他列内容。  
![在这里插入图片描述][202004102133248.png]

### 2.7.2 优化思路二 ###

该方案适用于主键自增的表，可以把Limit 查询转换成某个位置的查询 。  
![在这里插入图片描述][20200410213405875.png]

## 2.8 8 使用SQL提示 ##

SQL提示，是优化数据库的一个重要手段，简单来说，就是在SQL语句中加入一些人为的提示来达到优化操作的目的。

### 2.8.1 USE INDEX ###

在查询语句中表名的后面，添加 use index 来提供希望MySQL去参考的索引列表，就可以让MySQL不再考虑其他可用的索引。

create index idx_seller_name on tb_seller(name);

![在这里插入图片描述][20200410213917627.png]

### 2.8.2 IGNORE INDEX ###

如果用户只是单纯的想让MySQL忽略一个或者多个索引，则可以使用 ignore index 作为 hint 。

explain select * from tb_seller ignore index(idx_seller_name) where name = '小米科 技';

### 2.8.3 FORCE INDEX ###

为强制MySQL使用一个特定的索引，可在查询中使用 force index 作为hint

create index idx_seller_address on tb_seller(address);

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70]: /images/20230528/c43f7f1d94a044e0a7721561ff379ceb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 1]: /images/20230528/00e4919a6be3467093a2ebcca554afd6.png
[20200410173928881.png]: /images/20230528/7a2550fda438411bb1b8ba1b1cc05555.png
[20200410174657890.png]: /images/20230528/e6e181aa597441cd841363787156c527.png
[20200410174739929.png]: /images/20230528/bd9e3796dc1549bda1c47337ddee3c70.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 2]: /images/20230528/b6a77b945ad649d3bf89c55211cfe8d7.png
[20200410175030257.png]: /images/20230528/e2c34d88b6cb4787b64aa827f66a0aac.png
[20200410175134957.png]: /images/20230528/f43263d2cce5478d86431488469917ee.png
[20200410180227451.png]: /images/20230528/1482282a358f469ab8a6fc584c8beed6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 3]: /images/20230528/6995909b28f149c8ad9d9732d05cab56.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 4]: /images/20230528/74a12f559b5647eaac747e8c28bd237d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 5]: /images/20230528/7b01fbd7a30e4ec4a6c9d5999c636f69.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 6]: /images/20230528/cc9ec3bf12aa4ba1954a7eaaed78166e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 7]: /images/20230528/a9551e5804b642f1aa84d4891d0c6392.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 8]: /images/20230528/edf3139f60d341c3ad52a381e1346f2e.png
[20200410212844173.png]: /images/20230528/a417917981e343d2b16b2f59069d4475.png
[20200410212936739.png]: /images/20230528/a1140ae966dd4e75bf8558f44d79c26c.png
[202004102133248.png]: /images/20230528/e614c4b9a3354de38b09208dddb142c4.png
[20200410213405875.png]: /images/20230528/5c468d679d854e9b9e245e75d63818bd.png
[20200410213917627.png]: /images/20230528/baab931a8aa04e53bf80a32b33d5c253.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU5NjkwNQ_size_16_color_FFFFFF_t_70 9]: /images/20230528/a020b504b2924964912ef18818b2cffc.png