很惭愧，写了快两年的SQL，突然发现SQL性能优化需要注意的点自己竟然不知道。趁着今天下班比较早，还有剩余电量，先把百度能搜罗到的答案整理如下，为尊重原创，来源均备注出处。
表连接和内嵌：
1、连接的表越多、性能越差，尽可能将表连接分拆成若干个过程逐一执行
2、尽量避免使用外连接，因为需要左右表都扫描
3、使用临时表，少用子查询，减少内嵌层数
语句优化：
1、exists/anti join/semi join替代in
not in是最低效的，因为要对子查询的表进行全表扫描。可以考虑使用外链接或not exists。如下：
select * from 表A where id in (select id from 表B)
相当于
select * from 表A where exists(select * from 表B where 表B.id=表A.id)
相当于
select * from 表A left semi join 表B on 表B.id=表A.id
select colname … from A表 where a.id not in (select b.id from B表)
相当于
select colname … from A表 left join B表 on where a.id = b.id where b.id is null
相当于
select colname … from A表 left anti join B表 on where a.id = b.id
2、尽量用union all代替union，union all或union代替or
union具有去重的操作，增加了计算时间。union all不需要去重，但会包含相同记录。同样功能下，首选union all操作。
-- 高效:
SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10
UNION
SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE REGION = 'MELBOURNE'
-- 低效:
SELECT LOC_ID ,LOC_DESC ,REGION FROM LOCATION WHERE LOC_ID=10 OR REGION ='MELBOURNE'
3、>与>=
-- 直接定位到4的记录(推荐)
select .. from .. where SAL >= 4 ;
-- 先定位到3，再向后找1个(不推荐)
select .. from .. where SAL > 3 ;
4、SELECT语句务必指明字段名称
不要用select * ，SELECT*增加很多不必要的消耗（CPU、IO、内存、网络带宽）；增加了使用覆盖索引的可能，所以要求直接在select后面接上字段名。
5、避免在where子句中对字段进行null值判断
对于null的判断会导致引擎放弃使用索引而进行全表扫描。
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
6、尽量避免在 where 子句中使用!=或<>操作符
否则将引擎放弃使用索引而进行全表扫描。
7、避免在 where 子句中使用 or 来连接条件
否则将导致引擎放弃使用索引而进行全表扫描
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
8、避免在where子句中对字段进行函数操作，
这将导致引擎放弃使用索引而进行全表扫描
select id from t where substring(name,1,3)='abc'--name以abc开头的id
应改为:
select id from t where name like 'abc%'
9、对于联合索引来说，要遵守最左前缀法则
举列来说索引含有字段id、name、school，可以直接用id字段，也可以id、name这样的顺序，但是name;school都无法使用这个索引。所以在创建联合索引的时候一定要注意索引字段顺序，常用的查询字段放在最前面。
10、like
通配符出现在首位，无法使用索引，反之可以。
-- 无法使用索引
select .. from .. where name like '%t%' ;
-- 可以使用索引
select .. from .. where name like 't%' ;
内容来源：
https://www.cnblogs.com/xupccc/p/9661972.html
http://blog.itpub.net/31555484/viewspace-2565387/
https://blog.csdn.net/qq_38789941/article/details/83744271