查询优化

查询慢的原因

网络 CPU IO 上下文切换 系统调用 生成统计信息 锁等待

优化数据访问

查询性能低下的主要原因是访问的数据太多 需要避免检索、传输大量数据

访问了太多行和列

如果是由于访问太多行，则首先应避免写出这种SQL，MySQL会直接返回客户端所查询的全部数据，所以可以使用LIMIT来进行限制

访问了太多的列，则应该审视是否真的需要这些列，其次可以通过覆盖索引扫描的方式来进行优化。

MySQL扫描了过多的数据行

通过检查慢日志记录可以找出扫描行数过多的查询。

也可以通过EXPLAIN语句列出结果rows属性，理想情况下扫描的行和返回的行数量一致。

如果要对扫描行数与返回行数量相差较多的查询进行优化，主要可以通过

  1. 覆盖索引扫描的方式
  2. 改变表结构 使用单独的汇总表之类的
  3. 重写掉这个复杂的查询

重构查询

一个大查询如果一次性执行的话，可能一次锁住很多数据、占满整个事务日志、耗尽系统资源

对于一些操作数据量大的SQL，如果可以将其拆分成几个小SQL，在应用层进行处理，那可以把服务器的压力分摊到各个时间点中。

如可以对一些关联查询进行分解：

  1. 可以利用缓存
  2. 降低锁争用
  3. 应用层处理拥有较高的可扩展性
  4. 单表查询效率可能比连接高
  5. ...

查询执行

屏幕截图 2021-03-16 152127

一条查询SQL的执行流程：

  1. 先进行缓存查询，如果命中缓存，则直接返回，否则继续
  2. 接下来会对SQL进行解析与处理，将SQL转为AST，语法错误在这个阶段被发现
  3. 接下来走到优化器，这个阶段会根据策略找到MySQL认为最优的执行方式
  4. 最后走到执行引擎这里，有大量的操作需要通过调用存储引擎实现的接口来完成，如调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是 10，如果不是则跳过，如果是则将这行存在结果集中，慢查询日志有个rows_examined字段，表示了在执行这条SQL语句时，MySQL扫描了多少行数据

被废弃的查询缓存

从5.6开始 MySQL就禁用了缓存 8.0更是废弃了缓存

为甚要禁用

通信协议

MySQL的数据传输是半双工，一方发送完数据包后，必须等待对方回应才能进行下一步操作。通过设置max_allowed_packet参数来限制数据包大小

每个MySQL连接都有类似于线程的状态，通过这些状态可以发现一些不正常的连接：

SHOW FULL PROCESSLIST

Sleep、Query、Locked... 参考general-thread-states

查询优化处理

sql -> 语法树 -> 查询优化器 -> 选择优化器认为最佳的执行计划 -> 执行

由于种种原因，优化器最后可能会选择错误的执行计划

优化器计算的依据

优化策略

优化类型

关联查询执行

屏幕截图 2021-10-27 172202

排序优化

当排序的数据量过大，则会在文件中进行排序（filesort），使用两次传输排序或者单次传输排序，排序时消耗的临时磁盘空间要比排序的数据本身大得多。所以尽量使用LIMIT子句来降低需要排序的数据量。

MySQL 会给每个线程分配一块内存用于排序，称为 sort_buffer，排序过程是否在内存中完成，取决于排序所需的内存和参数 sort_buffer_size，sort_buffer_size 越小，需要分成的份数越多，也就需要更多的临时文件

全字段排序（单次传输排序）：

  1. 初始化 sort_buffer，放入 select 指定的字段
  2. 不断找出满足记录的数据，取出 select 指定的字段放入 sort_buffer
  3. 对 sort_buffer 中的数据按照排序字段排序

max_length_for_sort_data，是 MySQL 中专门控制用于排序的行数据的长度的一个参数。它的意思是，如果单行的长度超过这个值，就改用两次传输排序

rowid 排序（两次传输排序）：

  1. 初始化 sort_buffer
  2. **找出满足记录的数据的主键，根据主键再回表查到所需要的字段**
  3. 对 sort_buffer 中的数据按照排序字段排序

并不是所有的 order by 子句都需要进行排序，如果索引合适，MySQL 可以直接利用索引的有序性直接得到有序结果，甚至还不用回表：

-- 如果在这张表上有个联合索引(city,name)SELECT city,name FROM person WHERE city = '厦门' ORDER BY name

order by rand()：这个语句需要 Using temporary 和 Using filesort，查询的执行代价往往是比较大的，内存临时表排序的时候使用了 rowid 排序方法

  1. 创建一个临时表，除了 select 的字段之外，还有一个一个随机值
  2. 按照随机值排序

tmp_table_size 这个配置限制了内存临时表的大小，默认值是 16M。如果临时表大小超过了 tmp_table_size，那么内存临时表就会转成磁盘临时表

优化器的局限

给优化器提示

通过给SQL语句加上一些标志，比如常见的INSERT DELAYED，来明确控制优化器的行为

若非必要，不要使用这些提示，每次MySQL新版本都会加入许多优化策略，这些提示可能会造成优化策略失效

https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html

优化特定类型查询

count 查询

COUNT(列或表达式) 计算的是列或表达式有值(非NULL)的数量，而COUNT(*) 计算的就是结果集数。

count(主键 id)：遍历整张表，把每一行的 id 值都取出来拿到 id 后，判断是不可能为空的，就按行累加

count(1)：遍历整张表，但不取值，对于返回的每一行，放一个数字“1”进去，判断是不可能为空的，按行累加

count(字段)：对于有可能是 null的，还要把值取出来再判断一下，不是 null 才累加

count(*)：是例外，专门做了优化，不取值。这个count返回的每一行肯定不是 null，按行累加

按照效率排序的话，count(字段)<count(主键 id)<count(1)≈count(*)

关联查询

子查询优化

limit 分页大偏移量优化

SELECT * FROM xx   INNER JOIN(SELECT id FROM xx LIMIT 999,5)
SELECT * FROM xx WHERE id > 1000 LIMIT 5

优化union查询

除非确实需要服务器消除重复的行，否则一定要使用union all

使用用户自定义变量

SET @last_week := CURRENT_DATE-INTERVAL 1 WEEK;SELECT @last_week;

使用限制：无法使用查询缓存、变量的生存域在连接中

使用索引

索引的原理：

屏幕截图 2020-08-27 093235

MySQL 使用索引的方式：

索引的代价：

挑选索引：

查询优化程序

EXPLAIN SELECT * FROM person WHERE FALSE

有助于优化程序对索引充分利用：

数据类型高效查询

表存储格式高效查询

MyISAM:

MEMORY:

InnoDB：

CREATE TABLE tb (...) ROW_FORMAT = xxx;

高效加载数据

调度 锁定 并发

调度策略：

InnoDB: 行级锁 更精细 并发度更高

MyISAM: 表级锁 不会出现死锁问题