MySQL常见优化
1.操作符优化
1.1<> 操作符（不等于）
优化原因:
不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。
优化方法:
a): 用其它相同功能的操作运算代替，如 a<>0 改为 a>0 or a<0 a<>'' 改为 a>''
b): 尽量便面使用 != 操作符,如 c != '' 应写成 c > ''
1.2LIKE优化
优化方法:
a): LIKE '名称%'-----可以使用到索引,可以使用
b): LIKE '%名称%'----不会使用索引,尽量避免使用,只能在语句上进行优化
原SQL: Select object_id,object_type,object_name from t1
where object_name like '%ABC%';
改写后的SQL：Select object_id ,object_type,object_name from t1
Where object_name in
(select object_name from t1 where object_name like '%ABC%');
c): LIKE '%名称'-----不会使用到索引,应优化
1: 首先,在查询的列建立反向索引
cerate index 索引名称 on 表名(reverse(列名));
2: 查询语句如下:
select count(*) from emp where reverse(列名) like reverse('%名称');
用全文搜索搜索文本数据，取代like搜索
全文搜索始终优于like搜索：
(1)全文搜索让你可以实现like不能完成的复杂搜索，如搜索一个单词或一个短语，搜索一个与另一个单词或短语相近的单词或短语，或者是搜索同义词;
(2)实现全文搜索比实现like搜索更容易(特别是复杂的搜索);
1.3in,not in,exists与not exists
1.3.1in和exists
in是把外表和内表作hash连接，而exists是对外表作loop循环，每次loop循环再对内表进行查询，一直以来认为exists比in效率高的说法是不准确的。
如果查询的两个表大小相当，那么用in和exists差别不大；如果两个表中一个较小一个较大，则子查询表大的用exists，子查询表小的用in；
例如：表A(小表)，表B(大表)
select * from A where cc in(select cc from B) -->效率低，用到了A表上cc列的索引；
select * from A where exists(select cc from B where cc=A.cc) -->效率高，用到了B表上cc列的索引。
相反的：
select * from B where cc in(select cc from A) -->效率高，用到了B表上cc列的索引
select * from B where exists(select cc from A where cc=B.cc) -->效率低，用到了A表上cc列的索引。
Not IN 不走索引的是绝对不能用的，可以用NOT EXISTS 代替
2.where子句优化
2.1第一个原则：在where子句中应把最具限制性的条件放在最前面。
在下面两条select语句中:
select * from table1 where field1<=10000 and field1>=0;
select * from table1 where field1>=0 and field1<=10000;
如果数据表中的数据field1都>=0,则第一条select语句要比第二条select语句效率高的多，
因为第二条select语句的第一个条件耗费了大量的系统资源。
2.2第二个原则：where子句中字段的顺序应和索引中字段顺序一致。
在下面的select语句中:
select * from tab where a=… and b=… and c=…;
若有索引index(a,b,c)，则where子句中字段的顺序应和索引中字段顺序一致。
2.3应尽量避免在 where 子句中使用 or 来连接条件，
如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or Name = 'admin'
可以这样查询：
select id from t where num = 10
union all
select id from t where Name = 'admin'
2.4应尽量避免在 where 子句中等号的左端对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2 = 100
应改为:
select id from t where num = 100*2
2.5在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，
否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。(不需要完全一致。最左前缀原则。)
以下假设在field1上有唯一索引I1，在field2上有非唯一索引I2。
1):
a):
select field3,field4 from tb where field1='sdf' 快
select * from tb where field1='sdf' 慢，
因为后者在索引扫描后要多一步ROWID表访问。
b):
select field3,field4 from tb where field1>='sdf' 快
select field3,field4 from tb where field1>'sdf' 慢
因为前者可以迅速定位索引。
c):
select field3,field4 from tb where field2 like 'R%' 快
select field3,field4 from tb where field2 like '%R' 慢，
因为后者不使用索引。
2) 使用函数如：
select field3,field4 from tb where upper(field2)='RMN'不使用索引。
如果一个表有两万条记录，建议在WHERE子句中不使用函数；
如果一个表有五万条以上记录，在WHERE子句中严格禁止使用函数！两万条记录以下没有限制。
3.SQL语句注意事项
3.1在查询中不要使用select *
为什么不能使用，地球人都知道，但是很多人都习惯这样用，要明白能省就省，而且这样查询数据库不能利用“覆盖索引”了
3.2尽量写WHERE子句
尽量不要写没有WHERE的SQL语句
3.3注意SELECT INTO后的WHERE子句
因为SELECT INTO把数据插入到临时表，这个过程会锁定一些系统表，如果这个WHERE子句返回的数据过多或者速度太慢，会造成系统表长期锁定，诸塞其他进程。
3.4对于聚合查询，可以用HAVING子句进一步限定返回的行
3.5避免使用临时表
(1)除非却有需要，否则应尽量避免使用临时表，相反，可以使用表变量代替;
(2)大多数时候(99%)，表变量驻扎在内存中，因此速度比临时表更快，临时表驻扎在TempDb数据库中，因此临时表上的操作需要跨数据库通信，速度自然慢。
3.6减少访问数据库的次数：
程序设计中最好将一些常用的全局变量表放在内存中或者用其他的方式减少数据库的访问次数
3.7尽量少做重复的工作
尽量减少无效工作，但是这一点的侧重点在客户端程序，需要注意的如下：
A、控制同一语句的多次执行，特别是一些基础数据的多次执行是很多程序员很少注意的
B、减少多次的数据转换，也许需要数据转换是设计的问题，但是减少次数是程序员可以做到的。
C、杜绝不必要的子查询和连接表，子查询在执行计划一般解释成外连接，多余的连接表带来额外的开销。
D、合并对同一表同一条件的多次UPDATE，比如
UPDATE EMPLOYEE SET FNAME=‘HAIWER’ WHERE EMP_ID=‘VPA30890F’
UPDATE EMPLOYEE SET LNAME=‘YANG’ WHERE EMP_ID=‘VPA30890F’
这两个语句应该合并成以下一个语句
UPDATE EMPLOYEE SET FNAME=‘HAIWER’,LNAME=‘YANG’
WHERE EMP_ID=’ VPA30890F’
E、UPDATE操作不要拆成DELETE操作+INSERT操作的形式，虽然功能相同，但是性能差别是很大的。
F、不要写一些没有意义的查询，比如
SELECT * FROM EMPLOYEE WHERE 1=2