尽量使用索引避免全表扫描
1.模糊查询的效率很低。
可以使用"sql%"这种右模糊 ，避免使用类似“%sql优”或者"%ql优%"类型的模糊查询，无法避免的话使用reverse + function index方式。
---对于 like '...%' 的 (不以 % 开头)的sql，可以通过加索引来提高速度；
----尽量不要使用 like '%..%'
---对于 like '%…' 的 (不以 % 结尾)的sql
select id,name from stu where name like '%小';
select id,name from stu where reverse(name)like reverse('%小')；
2.查询条件中含有查询条件中含有is null;
原因： 查询字段is null时单索引失效，引起全表扫描
/**SQL语法中使用NULL会有很多麻烦，最好索引列都是NOT NULL的；
对于is null，可以建立组合索引，nvl(字段,0),对表和索引analyse后，
is null查询时可以重新启用索引查找,但是效率还不是值得肯定；
is not null 时永远不会使用索引。一般数据量大的表不要用is null查询。**/
--可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0 3.查询条件中遇到了不等于号（<>或者!=）
/**
通过把不等于操作符改成or，可以使用索引，避免全表扫描。例如，把column<>’aaa’，
改成column<’aaa’ or column>’aaa’，就可以使用索引了。
**/4.in 和 not in 也要慎用，否则会导致全表扫描
/**
select id from t where num in(1,2,3)
对于连续的数值，能用between 就不要用in 了：
select id from t where num between 1 and 3
**/
--用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b)
--用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num) 5.在where 子句中使用 or 来连接条件
/**
where子句中比较的两个条件，一个有索引，一个没索引，使用or则会引起全表扫描。
例如：where A=：1 or B=：2，A上有索引，B上没索引，则比较B=：2时会重新开始全表扫描。
**/
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 6.Update 语句，如果只更改1、2个字段，不要Update全部字段;
7.对于多张大数据量(这里几百条就算大了)的表JOIN，要先分页再JOIN，否则逻辑读会很高，性能很差。
8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2
9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)='abc'
--name以abc开头的id
select id from t where datediff(day,createdate,'2005-11-30')=0
--‘2005-11-30’生成的id应改为:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1' 10.如果在where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推 迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num10 11.where子句中对字段进行表达式操作的优化
不要在where子句中的“=”左边进行函数、算数运算或其他表达式运算，否则系统将可能无法正确使用索引。
如SQL:SELECT id FROM A WHERE num/2 = 100 优化成：SELECT id FROM A WHERE num = 100*2
如SQL:SELECT id FROM A WHERE substring(name,1,3) = 'abc' 优化成：SELECT id FROM A WHERE LIKE 'abc%'
如SQL:SELECT id FROM A WHERE datediff(day,createdate,'2016-11-30')=0
优化成：SELECT id FROM A WHERE createdate>='2016-11-30' and createdate<'2016-12-1'
如SQL:SELECT id FROM A WHERE year(addate) <2016 优化成：SELECT id FROM A where addate<'2016-01-01'12.Inner join 和 left join、right join、子查询
第一：inner join内连接也叫等值连接是，left/rightjoin是外连接。
SELECT A.id,A.name,B.id,B.name FROM A LEFT JOIN B ON A.id =B.id;
SELECT A.id,A.name,B.id,B.name FROM A RIGHT JOIN ON B A.id= B.id;
SELECT A.id,A.name,B.id,B.name FROM A INNER JOIN ON A.id =B.id;
经过来之多方面的证实inner join性能比较快，因为inner join是等值连接
，或许返回的行数比较少。但是我们要记得有些语句隐形的用到了等值连接，如：
SELECT A.id,A.name,B.id,B.name FROM A,B WHERE A.id = B.id;
推荐：能用inner join连接尽量使用inner join连接
第二：子查询的性能又比外连接性能慢，尽量用外连接来替换子查询。
select* from A where exists (select * from B where id>=3000 and A.uuid=B.uuid);
A表的数据为十万级表，B表为百万级表，在本机执行差不多用2秒左右，
我们可以通过explain可以查看到子查询是一个相关子查询(DEPENDENCE SUBQUERY);
Mysql是先对外表A执行全表查询，
然后根据uuid逐次执行子查询，如果外层表是一个很大的表，
我们可以想象查询性能会表现比这个更加糟糕。
一种简单的优化就是用innerjoin的方法来代替子查询，查询语句改为：
Select* from A inner join B ON A.uuid=B.uuid using(uuid) where b.uuid>=3000;
这个语句执行测试不到一秒；
第三：使用JOIN时候，应该用小的结果驱动打的结果（left join 左边表结果尽量小，
如果有条件应该放到左边先处理，right join同理反向），同时尽量把牵涉到多表联合的查询拆分多个 query(多个表查询效率低，容易锁表和阻塞)。如：
Select * from A left join B A.id=B.ref_id where A.id>10;
可以优化为：select * from (select * from A wehre id >10) 13、尽量用 union add 替换 union
union和union all的差异主要是前者需要将两个（或者多个）结果集合并后再进行唯一性过滤操作，这就会涉及到排序，增加大量的cpu运算，加大资源消耗及延迟。所以当我们可以确认不可能出现重复结果集或者不在乎重复结果集的时候，尽量使用union all而不是union
https://blog.csdn.net/wendy432/article/details/52319908