前言
本文将结合实例demo，阐述30条有关于优化SQL的建议，多数是实际开发中总结出来的，希望对大家有帮助。
1、查询SQL尽量不要使用select *，而是select具体字段。
反例子：
正例子：
理由：
2、如果知道查询结果只有一条或者只要最大/最小一条记录，建议用limit 1
假设现在有employee员工表，要找出一个名字叫jay的人.
反例：
正例
理由：
3、应尽量避免在where子句中使用or来连接条件
新建一个user表，它有一个普通索引userId，表结构如下：
假设现在需要查询userid为1或者年龄为18岁的用户，很容易有以下sql
反例:
正例：
理由：
对于or+没有索引的age这种情况，假设它走了userId的索引，但是走到age查询条件时，它还得全表扫描，也就是需要三步过程：全表扫描+索引扫描+合并如果它一开始就走全表扫描，直接一遍扫描就完事。mysql是有优化器的，处于效率与成本考虑，遇到or条件，索引可能失效，看起来也合情合理。
4、优化limit分页
我们日常做分页需求时，一般会用 limit 实现，但是当偏移量特别大的时候，查询效率就变得低下。
反例：
正例：
理由：
5、优化你的like语句
日常开发中，如果用到模糊关键字查询，很容易想到like，但是like很可能让你的索引失效。
反例：
正例：
理由：
6、使用where条件限定要查询的数据，避免返回多余的行
假设业务场景是这样：查询某个用户是否是会员。曾经看过老的实现代码是这样。。。
反例：
正例：
理由：
7、尽量避免在索引列上使用mysql的内置函数
业务需求：查询最近七天内登陆过的用户(假设loginTime加了索引)
反例：
正例：
理由：
img8、应尽量避免在 where 子句中对字段进行表达式操作，这将导致系统放弃使用索引而进行全表扫
反例：
正例：
理由：
9、Inner join 、left join、right join，优先使用Inner join，如果是left joinsql取最大的一条数据，左边表结果尽量小
都满足SQL需求的前提下，推荐优先使用Inner join（内连接），如果要使用left join，左边表数据结果尽量小，如果有条件的尽量放到左边处理。
反例:
正例：
理由：
10、应尽量避免在 where 子句中使用!=或操作符，否则将引擎放弃使用索引而进行全表扫描。
反例：
正例：
理由：
img11、使用联合索引时，注意索引列的顺序，一般遵循最左匹配原则。
表结构：（有一个联合索引idx_userid_age，userId在前，age在后）
反例：
img
正例：
理由：
12、对查询进行优化，应考虑在 where 及 order by 涉及的列上建立索引，尽量避免全表扫描。
反例：
正例：
img13、如果插入数据过多，考虑批量插入。
反例：
正例：
理由：
打个比喻:假如你需要搬一万块砖到楼顶,你有一个电梯,电梯一次可以放适量的砖（最多放500）,你可以选择一次运送一块砖,也可以一次运送500,你觉得哪个时间消耗大?
14、在适当的时候，使用覆盖索引。
覆盖索引能够使得你的SQL语句不需要回表，仅仅访问索引就能够得到所有需要的数据，大大提高了查询效率。
反例：
正例：
img15、慎用distinct关键字
distinct 关键字一般用来过滤重复记录，以返回不重复的记录。在查询一个字段或者很少字段的情况下使用时，给查询带来优化效果。但是在字段很多的时候使用，却会大大降低查询效率。
反例：
正例：
理由：
16、删除冗余和重复索引
反例：
正例:
理由：
17、如果数据量较大，优化你的修改/删除语句。
避免同时修改或删除过多数据，因为会造成cpu利用率过高，从而影响别人对数据库的访问。
反例：
正例：
理由：
18、where子句中考虑使用默认值代替null。
反例：
正例：
理由：
如果mysql优化器发现，走索引比不走索引成本还要高，肯定会放弃索引，这些条件！=，>is null，is not null经常被认为让索引失效，其实是因为一般情况下，查询的成本高，优化器自动放弃的。
19、不要有超过5个以上的表连接20、exist & in的合理利用
假设表A表示某企业的员工表，表B表示部门表，查询所有部门的所有员工，很容易有以下SQL:
这样写等价于：
先查询部门表B
select deptId from B
再由部门deptId，查询A的员工
select * from A where A.deptId = B.deptId
可以抽象成这样的一个循环：
显然，除了使用in，我们也可以用exists实现一样的查询功能，如下：
因为exists查询的理解就是，先执行主查询，获得数据后，再放到子查询中做条件验证，根据验证结果（true或者false），来决定主查询的数据结果是否得意保留。
那么，这样写就等价于：
select * from A,先从A表做循环
select * from B where A.deptId = B.deptId,再从B表做循环.
同理，可以抽象成这样一个循环：
数据库最费劲的就是跟程序链接释放。假设链接了两次，每次做上百万次的数据集查询，查完就走，这样就只做了两次；相反建立了上百万次链接，申请链接释放反复重复，这样系统就受不了了。即mysql优化原则，就是小表驱动大表，小的数据集驱动大的数据集，从而让性能更优。
因此，我们要选择最外层循环小的，也就是，如果B的数据量小于A，适合使用in，如果B的数据量大于A，即适合选择exist。
21、尽量用 union all 替换 union
如果检索结果中不会有重复的记录，推荐union all 替换 union。
反例：
正例：
理由：
22、索引不宜太多，一般5个以内。23、尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型
反例：
正例：
理由：
24、索引不适合建在有大量重复数据的字段上，如性别这类型数据库字段。
因为SQL优化器是根据表中数据量来进行查询优化的，如果索引列有大量重复数据，Mysql查询优化器推算发现不走索引的成本更低sql取最大的一条数据，很可能就放弃索引了。
25、尽量避免向客户端返回过多数据量。
假设业务需求是，用户请求查看自己最近一年观看过的直播数据。
反例：
正例：
26、当在SQL语句中连接多个表时,请使用表的别名，并把别名前缀于每一列上，这样语义更加清晰。
反例：
正例：
27、尽可能使用varchar/nvarchar 代替 char/nchar。
反例：
正例：
理由：
28、为了提高group by 语句的效率，可以在执行到该语句前，把不需要的记录过滤掉。
反例：
正例：
29、如何字段类型是字符串，where时一定用引号括起来，否则索引失效
反例：
正例：
理由：
30、使用explain 分析你SQL的计划
日常开发写SQL的时候，尽量养成一个习惯吧。用explain分析一下你写的SQL，尤其是走不走索引这一块。
img参考与感谢
作者 ：捡田螺的小男孩
———END———
限 时 特 惠：本站每日持续更新海量各大内部创业教程，一年会员只需128元，全站资源免费下载点击查看详情
站 长 微 信：jiumai99
