SQL优化

前提   {如果描述与下方冲突 以此为准}

【1】、（   用mysql测试了下， !=、<>、 in 、not in都会走索引,or连接的前后两个条件中的列都是索引时，也会走索引   ）

【2】、（不知道长度的情况下,varchar省空间,但是char查询效率高） 

【3】、like 中  ‘XXX%’ 走索引   否则全表扫描   【%放在前面会失效，这也体现出和es，solr检索查询的区别    】

【4】、在忽略I/O的情况下，仅仅从CPU的耗时来看，表现  优  ——> 差    ：   [ >=    <= \  between  and  ] >  [IN] >  [OR]

【5】、在两个独立索引上做 OR 操作，可以发现查询正确用到了索引，从执行计划的描述中，发现处理含有 OR 字段的查询是，实际上是对 OR 的各个字段分别查询后的结果进行了 UNION 操作。[索引生效的前提是直接字段索引 而不是复合索引*]

---

【like '汉字%' 也是不会走索引的 那些说后%会索引的 无一例外 都是用字母测试的 只有汉字是不行 具体原因还不清楚】

Explain命令在解决数据库性能上是第一推荐使用命令，大部分的性能问题可以通过此命令来简单的解决，Explain可以用来查看 SQL 语句的执行效 果

当type 显示为 “index” 时，并且Extra显示为“Using Index”， 表明使用了覆盖索引。 

key：显示MySQL实际决定使用的键（索引）。如果没有选择索引，键是NULL

key_len：显示MySQL决定使用的键长度。如果键是NULL，则长度为NULL。使用的索引的长度。在不损失精确性的情况下，长度越短越好

ref：显示使用哪个列或常数与key一起从表中选择行。

rows：显示MySQL认为它执行查询时必须检查的行数。

possible_keys：列指出MySQL能使用哪个索引在该表中找到行

=================================================

select_type：select_type就是select的类型，可以有以下几种：     

SIMPLE：简单SELECT(不使用UNION或子查询等)

PRIMARY：最外面的SELECT

UNION：UNION中的第二个或后面的SELECT语句

DEPENDENT UNION：UNION中的第二个或后面的SELECT语句，取决于外面的查询

UNION RESULT：UNION的结果。

SUBQUERY：子查询中的第一个SELECT

DEPENDENT SUBQUERY：子查询中的第一个SELECT，取决于外面的查询

DERIVED：导出表的SELECT(FROM子句的子查询)

=================================================

type： 性能有高往低
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

=================================================

Extra：包含MySQL解决查询的详细信息，也是关键参考项之一。

---

Distinct
一旦MYSQL找到了与行相联合匹配的行，就不再搜索了

Not exists
MYSQL 优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，

就不再搜索了

Range checked for each

Record（index map:#）
没有找到理想的索引，因此对于从前面表中来的每一 个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一

Using filesort
看 到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来 排序全部行

Using index
列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表 的全部的请求列都是同一个索引的部分的时候

Using temporary
看到这个的时候，查询需要优化了。这 里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上

Using where
使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index， 这就会发生，或者是查询有问题

---

---

1、避免SQL使用  字段为 null  的语句判断 否则将导致引擎放弃使用索引而进行全表扫描

错误示例： 

select * from hbkf_common_config where code_type = null ;

应该用 0  或者 " " 填充数值保证字段不为 null

2、!=    或者  <>  这样操作符导致 语句索引不可用 理由同上而造成全表扫描 [ mysql  5.2.7⬇ ]

2.1、 between比<=,>=的性能稍微多几十个   （这两个语句应该是等价的，唯一的可能是<=,>=需要提供两次整数，而between只要一次，节省了查询语句长度和传输数据大小）

3、避免使用 or 进行条件查询    改用 union all  或者 union 

错误示例

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    

4、not in  或者  in  慎用 乃至不用否则会导致全表扫描  [ mysql  5.2.7⬇ ]

错误示例： 

select id from t where num in(1,2,3)    

正确示例： (在连续数值可用)

select id from t where num between 1 and 3    

5、like '% %' 慎用，否则会导致全表扫描   （最好确定模糊方向）

select id from t where name like '%abc%'    

6、避免在数据库字段进行计算后比较 ；(不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。 ) 换成 计算完之后 = 

如下示例：

select id from t where num/2=100    

正确写法:

select id from t where num=100*2    

7、应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：    

select id from t where substring(name,1,3)='abc'--name以abc开头的id    

应为： 

select id from t where name like 'abc%'    	

8、能用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)    

9、如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。 

10、尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。    （使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。）

11、尽量避免大事务操作，提高系统并发能力（尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。）

12、在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log