浅谈SQL优化小技巧
MySQL 执行过程
SQL 语句性能优化常用策略
为 WHERE 及 ORDER BY 涉及的列上建立索引
对查询进行优化，应尽量避免全表扫描，首先应考虑在 WHERE 及 ORDER BY 涉及的列上建立索引。
where 中使用默认值代替 null
应尽量避免在 WHERE 子句中对字段进行 NULL 值判断，创建表时 NULL 是默认值，但大多数时候应该使用 NOT NULL，或者使用一个特殊的值，如 0，-1 作为默认值。
为啥建议where中使用默认值代替null，四个原因：
is null 或者 is not null 就会不走索引了，这个跟 mysql 版本以及查询成本都有关；慎用 != 或 <> 操作符
MySQL 只有对以下操作符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及某些时候的 LIKE。
所以：应尽量避免在 WHERE 子句中使用 != 或 <> 操作符， 会导致全表扫描。
慎用 OR 来连接条件
使用or可能会使索引失效，从而全表扫描；
应尽量避免在 WHERE 子句中使用 OR 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，
可以使用 UNION 合并查询：
select id from t where num=10
union all
select id from t where num=20
一个关键的问题是否用到索引。他们的速度只同是否使用索引有关，如果查询需要用到联合索引，用 UNION all 执行的效率更高。多个 OR 的字句没有用到索引，改写成 UNION 的形式再试图与索引匹配。
慎用 IN 和 NOT IN
IN 和 NOT IN 要慎用，否则会导致全表扫描。对于连续的数值，能用 BETWEEN 就不要用 IN：select id from t where num between 1 and 3。
慎用 左模糊 like '%…'
模糊查询，程序员最喜欢的就是使用like，like很可能让索引失效。
比如：
select id from t where name like‘%abc%’ select id from t where name like‘%abc’ 而select id from t where name like‘abc%’才用到索引。
所以：
首先尽量避免模糊查询，如果必须使用，不采用全模糊查询，也应尽量采用右模糊查询， 即like ‘…%’，是会使用索引的； 左模糊like ‘%…’无法直接使用索引，但可以利用reverse + function index的形式，变化成 like ‘…%’； 全模糊查询是无法优化的，一定要使用的话建议使用搜索引擎，比如 ElasticSearch。 备注：如果一定要用左模糊like ‘%…’检索， 一般建议 ElasticSearch+Hbase架构
WHERE 条件使用参数会导致全表扫描
如下面语句将进行全表扫描：
select id from t where num=@num
因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推 迟到 运行时；
它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。
所以， 可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
用 EXISTS 代替 IN 是一个好的选择
很多时候用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)
索引并不是越多越好
索引固然可以提高相应的 SELECT 的效率，但同时也降低了 INSERT 及 UPDATE 的效。
因为 INSERT 或 UPDATE 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。
一个表的索引数最好不要超过 6 个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
尽量使用数字型字段
所以：尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。
尽可能的使用 varchar, nvarchar 代替 char, nchar
因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
查询 SQL 尽量不要使用 select _，而是具体字段
最好不要使用返回所有：select from t ，用具体的字段列表代替 “”，不要返回用不到的任何字段。
select 的弊端：
将需要查询的结果预先计算好
将需要查询的结果预先计算好放在表中，查询的时候再Select，而不是查询的时候进行计算。
IN 后出现最频繁的值放在最前面
如果一定用IN，那么：在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，减少判断的次数。
尽量使用 EXISTS 代替 select count(1) 来判断是否存在记录。
count 函数只有在统计表中所有行数时使用，而且 count(1) 比 count(*) 更有效率。
用批量插入或批量更新
当有一批处理的插入或更新时，用批量插入或批量更新，绝不会一条条记录的去更新。
（1）多条提交
INSERT INTO user (id,username) VALUES(1,'xx');
INSERT INTO user (id,username) VALUES(2,'yy');
（2）批量提交
INSERT INTO user (id,username) VALUES(1,'xx'),(2,'yy');
默认新增SQL有事务控制，导致每条都需要事务开启和事务提交，而批量处理是一次事务开启和提交，效率提升明显，达到一定量级，效果显著，平时看不出来。
将不需要的记录在 GROUP BY 之前过滤掉
提高 GROUP BY 语句的效率，可以通过将不需要的记录在 GROUP BY 之前过滤掉。 下面两个查询返回相同结果，但第二个明显就快了许多。
-- 低效：
SELECT JOB, AVG(SAL) FROM EMP GROUP BY JOB HAVING JOB = 'PRESIDENT' OR JOB = 'MANAGER'
-- 高效：
SELECT JOB, AVG(SAL) FROM EMP WHERE JOB = 'PRESIDENT' OR JOB = 'MANAGER' GROUP BY JOB
避免死锁
在你的存储过程和触发器中访问同一个表时总是以相同的顺序；事务应经可能地缩短，在一个事务中应尽可能减少涉及到的数据量；永远不要在事务中等待用户输入。