SQL优化
https://blog.csdn.net/weixin_53601359/article/details/115553449
sql的语法顺序
1. SELECT <返回数据列表> # 返回的单列必须在group by子句中，聚合函数除外
2. DISTINCT <select_list> # 数据除重
3. FROM <left_table> <表名> # 选取表
4. <join_type> JOIN <right_table> # 指定join，用于添加数据到on之后的虚表中
5. ON <join_condition> <筛选条件> # 对笛卡尔积的虚表进行筛选
6. WHERE <where_condition> <where条件> # 对上述虚表进行筛选
7. GROUP BY <group_by_list> <分组条件> # 分组
8. HAVING <having_condition> <分组筛选> # 对分组后的结果进行聚合筛选
9. ORDER BY <order_by_condition> <排序条件> # 排序
10.LIMIT <limit_number> <行数限制>
sql的执行顺序
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 <行数限制>
MySQL优化遵循的五个原则
- 减少数据访问： 设置合理的字段类型，启用压缩，通过索引访问等减少磁盘IO
- 返回更少的数据： 只返回需要的字段和数据分页处理 减少磁盘io及网络io
- 减少交互次数： 批量DML操作，函数存储等减少数据连接次数
- 减少服务器CPU开销： 尽量减少数据库排序操作以及全表查询，减少cpu 内存占用
- 利用更多资源： 使用表分区，可以增加并行操作，更大限度利用cpu资源
总结到SQL优化中，就三点:
- 最大化利用索引；
- 尽可能避免全表扫描；
- 减少无效数据的查询；
基础SQL优化
- 查询SQL尽量不要使用select *，而是具体字段
反例: SELECT * FROM student
正例: SELECT id,NAME FROM student
理由：
- 字段多时，大表能达到100多个字段甚至达200多个字段
- 只取需要的字段，节省资源、减少网络开销
- select * 进行查询时，很可能不会用到索引，就会造成全表扫描
- 避免在where子句中使用or来连接条件
- 使用varchar代替char
- 尽量使用数值替代字符串类型
- 查询尽量避免返回大量数据
- 使用explain分析你SQL执行计划
- 是否使用了索引及其扫描类型
- 创建name字段的索引
- 优化like语句：
- 字符串怪现象
- 索引不宜太多，一般5个以内
- 索引不适合建在有大量重复数据的字段上
- where限定查询的数据
- 避免在索引列上使用内置函数
- 避免在where中对字段进行表达式操作
- 避免在where子句中使用!=或<>操作符
- 去重distinct过滤字段要少
- where中使用默认值代替null
高级SQL优化
- 批量插入性能提升
- 批量删除优化
- 伪删除设计
- 提高group by语句的效率
- 复合索引最左特性
- 排序字段创建索引
- 删除冗余和重复的索引
- 不要有超过5个以上的表连接
- inner join 、left join、right join，优先使用inner join
- in子查询的优化
- 尽量使用union all替代union
