（2022年最新版本）SQL优化最杆货总结 - MySQL

前言

BATJTMD等大厂的面试难度越来越高，但无论从大厂还是到小公司，一直未变的一个重点就是对SQL优化经验的考察。一提到数据库，先“说一说你对SQL优化的见解吧？”。SQL优化已经成为衡量程序猿优秀与否的硬性指标，甚至在各大厂招聘岗位职能上都有明码标注，如果是你，在这个问题上能吊打面试官还是会被吊打呢？

（注:如果看着模糊，可能是你撸多了）

有朋友疑问到，SQL优化真的有这么重要么？如下图所示，SQL优化在提升系统性能中是：（成本最低 && 优化效果最明显） 的途径。如果你的团队在SQL优化这方面搞得很优秀，对你们整个大型系统可用性方面无疑是一个质的跨越，真的能让你们老板省下不止几沓子钱。

• 优化成本：硬件>系统配置>数据库表结构>SQL及索引。
• 优化效果：硬件<系统配置<数据库表结构<SQL及索引。

String result = "嗯，不错，";
 
if ("SQL优化经验足") {
    if ("熟悉事务锁") {
        if ("并发场景处理666") {
            if ("会打王者荣耀") {
                result += "明天入职" 
            }
        }
    }
} else {
    result += "先回去等消息吧";
} 
 
Logger.info("面试官：" + result );

别看了，上面这是一道送命题。

好了我们言归正传，首先，对于MySQL层优化我一般遵从五个原则：

1. 减少数据访问： 设置合理的字段类型，启用压缩，通过索引访问等减少磁盘IO
2. 返回更少的数据： 只返回需要的字段和数据分页处理 减少磁盘io及网络io
3. 减少交互次数： 批量DML操作，函数存储等减少数据连接次数
4. 减少服务器CPU开销： 尽量减少数据库排序操作以及全表查询，减少cpu 内存占用
5. 利用更多资源： 使用表分区，可以增加并行操作，更大限度利用cpu资源

总结到SQL优化中，就三点:

• 最大化利用索引；
• 尽可能避免全表扫描；
• 减少无效数据的查询；

理解SQL优化原理 ，首先要搞清楚SQL执行顺序：

SELECT语句 - 语法顺序：

1. SELECT 
2. DISTINCT <select_list>
3. FROM <left_table>
4. <join_type> JOIN <right_table>
5. ON <join_condition>
6. WHERE <where_condition>
7. GROUP BY <group_by_list>
8. HAVING <having_condition>
9. ORDER BY <order_by_condition>
10.LIMIT <limit_number>

SELECT语句 - 执行顺序：

FROM

<表名> # 选取表，将多个表数据通过笛卡尔积变成一个表。

ON

<筛选条件> # 对笛卡尔积的虚表进行筛选

JOIN <join, left join, right join...>

<join表> # 指定join，用于添加数据到on之后的虚表中，例如left join会将左表的剩余数据添加到虚表中

WHERE

<where条件> # 对上述虚表进行筛选

GROUP BY

<分组条件> # 分组

<SUM()等聚合函数> # 用于having子句进行判断，在书写上这类聚合函数是写在having判断里面的

HAVING

<分组筛选> # 对分组后的结果进行聚合筛选

SELECT

<返回数据列表> # 返回的单列必须在group by子句中，聚合函数除外

DISTINCT

# 数据除重

ORDER BY

<排序条件> # 排序

LIMIT

<行数限制>

SQL优化策略

声明：以下SQL优化策略适用于数据量较大的场景下，如果数据量较小，没必要以此为准，以免画蛇添足。

一、避免不走索引的场景

1. 尽量避免在字段开头模糊查询，会导致数据库引擎放弃索引进行全表扫描。如下&#