如何优化慢SQL？

在应用开发的早期，数据量少，开发人员开发功能时更重视功能上的实现，随着生产数据的增长，很多 SQL 语句开始暴露出性能问题，对生产的影响也越来越大，有时可能这些有问题的 SQL 就是整个系统性能的瓶颈。

需要重点关注 type、rows、filtered、extra。

type 由上至下，效率越来越高：

Extra：

Using filesort：MySQL 需要额外的一次传递，以找出如何按排序顺序检索行。通过根据联接类型浏览所有行并为所有匹配 WHERE 子句的行保存排序关键字和行的指针来完成排序。然后关键字被排序，并按排序顺序检索行；

Using temporary：使用了临时表保存中间结果，性能特别差，需要重点优化；

Using index：表示相应的 select 操作中使用了覆盖索引（Coveing Index）,避免访问了表的数据行，效率不错！如果同时出现 using where，意味着无法直接通过索引查找来查询到符合条件的数据；

Using index condition：MySQL5.6 之后新增的 ICP，using index condtion 就是使用了 ICP（索引下推），在存储引擎层进行数据过滤，而不是在服务层过滤，利用索引现有的数据减少回表的数据。

了解 SQL 执行的线程的状态及消耗的时间。

默认是关闭的，开启语句“set profiling = 1;”

trace 分析优化器如何选择执行计划，通过 trace 文件能够进一步了解为什么优惠券选择 A 执行计划而不选择 B 执行计划。

如下：

优化索引

优化 SQL 语句：修改 SQL、IN 查询分段、时间查询分段、基于上一次数据过滤

改用其他实现方式：ES、数仓等

数据碎片处理

索引：

SQL 语句：

查询匹配从左往右匹配，要使用 order_no 走索引，必须查询条件携带 shop_id 或者索引（shop_id，order_no）调换前后顺序。

索引：

SQL 语句：

隐式转换相当于在索引上做运算，会让索引失效。mobile 是字符类型，使用了数字，应该使用字符串匹配，否则 MySQL 会用到隐式替换，导致索引失效。

索引：

SQL 语句：

对于大分页的场景，可以优先让产品优化需求，如果没有优化的，有如下两种优化方式：

一种是把上一次的最后一条数据，也即上面的 c 传过来，然后做“c

另一种是采用延迟关联的方式进行处理，减少 SQL 回表，但是要记得索引需要完全覆盖才有效果。

SQL改动如下：

索引：

SQL 语句：

in 查询在 MySQL 底层是通过 n*m 的方式去搜索，类似 union，但是效率比 union 高。

in 查询在进行 cost 代价计算时（代价 = 元组数 * IO 平均值），是通过将 in 包含的数值，一条条去查询获取元组数的，因此这个计算过程会比较的慢。

所以 MySQL 设置了个临界值（eq_range_index_dive_limit），5.6 之后超过这个临界值后该列的 cost 就不参与计算了。因此会导致执行计划选择不准确。

默认是 200，即 in 条件超过了 200 个数据，会导致 in 的代价计算存在问题，可能会导致 MySQL 选择的索引不准确。

处理方式：可以（order_status，created_at）互换前后顺序，并且调整 SQL 为延迟关联。

索引：

SQL 语句：

范围查询还有“IN、between”。

可以用到 ICP：

在索引上，避免使用 NOT、!=、、!、NOT EXISTS、NOT IN、NOT LIKE等。

如果要求访问的数据量很小，则优化器还是会选择辅助索引，但是当访问的数据占整个表中数据的蛮大一部分时（一般是 20% 左右），优化器会选择通过聚集索引来查找数据。

查询出所有未支付的订单，一般这种订单是很少的，即使建了索引，也没法使用索引。

如果是统计某些数据，可能改用数仓进行解决；如果是业务上就有那么复杂的查询，可能就不建议继续走 SQL 了，而是采用其他的方式进行解决，比如使用 ES 等进行解决。

desc 和 asc 混用时会导致索引失效。

对于推送业务的数据存储，可能数据量会很大，如果在方案的选择上，最终选择存储在 MySQL 上，并且做 7 天等有效期的保存。

那么需要注意，频繁的清理数据，会照成数据碎片，需要联系 DBA 进行数据碎片处理。