Mysql学习-04 索引优化分析--查询优化

索引的规则：

1.索引失效情况

<1>全值匹配我最爱 

    建立索引提高效率 CREATE INDEX 索引名字 ON 表名(表字段,表字段,表字段,......)

   建立索引前:

   

   索引后：

     

<2>最佳左前缀法则
     如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。 

  EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.age=30   AND emp.name = 'abcd'   

  

 虽然只是使用了一部分但是效率还是提高了。

 

 完全没有使用上索引

 结论：过滤条件要使用索引必须按照索引建立时的顺序，依次满足，一旦跳过某个字段，索引后面的字段都无法被使用。

<3>不在索引列上做任何操作（计算、函数、(自动or手动)类型转换），会导致索引失效而转向全表扫描

这两条sql哪种写法更好
SELECT SQL_NO_CACHE * FROM emp WHERE   emp.name  LIKE 'abc%' 
 
 SELECT SQL_NO_CACHE * FROM emp WHERE   LEFT(emp.name,3)  = 'abc'

第一种：

  

第二种：

  

<4>存储引擎不能使用索引中范围条件右边的列，可以将范围索引字段放置到索引中的最右位置

 如果系统经常出现的sql如下：
 SELECT  SQL_NO_CACHE * FROM emp WHERE emp.age=30 AND emp.deptId>20 AND emp.name = 'abc' ; 
 那么索引 idx_age_deptid_name这个索引还能正常使用么？

如果这种sql 出现较多。应该建立： create index idx_age_name_deptid on emp(age,name,deptid)
效果：

<5>mysql 在使用不等于(!= 或者<>)的时候无法使用索引会导致全表扫描

<6>is not null 也无法使用索引,但是is null是可以使用索引的

<7>like以通配符开头('%abc...')mysql索引失效会变成全表扫描的操作

<8>字符串不加单引号索引失效

总结：

2.建议

•   对于单键索引，尽量选择针对当前query过滤性更好的索引
•   在选择组合索引的时候，当前Query中过滤性最好的字段在索引字段顺序中，位置越靠前越好。
•   在选择组合索引的时候，尽量选择可以能够包含当前query中的where字句中更多字段的索引
•   书写sql语句时，尽量避免造成索引失效的情况
•   尽可能通过分析统计信息和调整query的写法来达到选择合适索引的目的

单表查询优化：

        当范围条件和group by 或者 order by  的字段出现二选一时 ，优先观察条件字段的过滤数量，如果过滤的数据足够多，而需要排序的数据并不多时，优先把索引放在范围字段上。反之，亦然。
 

关联查询优化：如 left join /right join/union等

建议

• 保证被驱动表的join字段已经被索引,该索引因该给属于驱动表中的字段
• left join 时，选择小表作为驱动表，大表作为被驱动表。
• inner join 时，mysql会自己帮你把小结果集的表选为驱动表。
• 子查询尽量不要放在被驱动表，有可能使用不到索引。

子查询优化：
   尽量不要使用not in  或者 not exists 用left outer join  on  xxx is null 替代

  如：

SELECT SQL_NO_CACHE * FROM emp a WHERE  id  NOT  IN(SELECT ceo FROM dept b2
 WHERE ceo IS NOT NULL) group by age having count(*)<10000

修改：

  EXPLAIN SELECT SQL_NO_CACHE a.* FROM  emp a LEFT OUTER JOIN dept b
  ON a.id =b.ceo WHERE    b.ceo IS   NULL
  group by age having count(*)<10000

order by关键字优化 

• 尽可能在索引列上完成排序操作，遵照索引建的最佳左前缀

      

CREATE TABLE `emp` (
 `id` INT(11) NOT NULL AUTO_INCREMENT,
 `name` VARCHAR(20) DEFAULT NULL,
  `age` INT(3) DEFAULT NULL,
 `deptid` INT(11) DEFAULT NULL,
  empno int  not null,
 PRIMARY KEY (`id`),
 KEY `fk_dept_id` (`deptId`)

) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
create index idx_age_deptid_name on emp (age,deptid,name) -- 创建索引
drop index idx_age_deptid_name on emp -- 删除索引
以下  是否能使用到索引，能否去掉using filesort 
1、explain  select * from emp order by age,deptid; -- Using filesort
不能 没有过滤条件 
2、 explain  select * from emp order by age,deptid limit 10; -- Using filesort
 #若无过滤排序折
3、  explain  select * from emp where age=45 order by deptid; -- Using where
4、explain  select * from emp where age=45 order by   deptid,name; -- Using where
5、explain  select * from emp where age=45 order by  deptid,empno;-- Using where; Using filesort
6、explain  select * from emp where age=45 order by  name,deptid;-- Using where; Using filesort
7、 explain select * from emp where deptid=45 order by age; -- Using where; Using filesort 
#顺序不对排序折
8、explain  select * from emp where age=45 order by age,deptid; -- Using where 
9、explain  select * from emp where age=45 order by  deptid,age; -- Using where
#值确定无须排序 
 10、 EXPLAIN  SELECT * FROM emp WHERE age=50 AND deptid >8000 ORDER BY NAME; -- Using index condition; Using where; Using filesort
11、  EXPLAIN  SELECT * FROM emp WHERE age=50 AND deptid >8000 ORDER BY deptid, NAME; -- Using index condition; Using where 
 #谁残还得谁来续
12、  explain select * from emp where age=45 order by  deptid desc, name desc ; -- Using where
13、 explain select * from emp where age=45 order by  deptid asc, name desc ;-- Using where; Using filesort
#南辕北辙排序折(排序顺序不一致)

• ORDER BY子句，尽量使用Index方式排序,避免使用FileSort方式排序
• 如果不在索引列上，filesort有两种算法：mysql就要启动双路排序和单路排序

     1.双路排序

         MySQL 4.1之前是使用双路排序,字面意思就是两次扫描磁盘，最终得到数据， 读取行指针和orderby列，对他们进行排序，然后扫描已经排序好的列表，按照列表中的值重新从列表中读取对应的数据输出。从磁盘取排序字段，在buffer进行排序，再从磁盘取其他字段。取一批数据，要对磁盘进行了两次扫描，众所周知，I\O是很耗时的，所以在mysql4.1之后，出现了第二种改进的算法，就是单路排序。

    3.单路排序
         从磁盘读取查询需要的所有列，按照order by列在buffer对它们进行排序，然后扫描排序后的列表进行输出， 它的效率更快一些，避免了第二次读取数据。并且把随机IO变成了顺序IO,但是它会使用更多的空间， 因为它把每一行都保存在内存中了。

    结论及引申出的问题
        由于单路是后出的，总体而言好过双路， 但是用单路有问题 ：在sort_buffer中，方法B比方法A要多占用很多空间，因为方法B是把所有字段都取出, 所以有可能取出的数据的总大小超出了sort_buffer的容量，导致每次只能取sort_buffer容量大小的数据，进行排序（创建tmp文件，多路合并），排完再取取sort_buffer容量大小，再排……从而多次I/O。本来想省一次I/O操作，反而导致了大量的I/O操作，反而得不偿失。

  4.优化策略
             增大sort_buffer_size参数的设置
             增大max_length_for_sort_data参数的设置
             减少select 后面的查询的字段。

     
  提高Order By的速度
      1. Order by时select * 是一个大忌只Query需要的字段， 这点非常重要。在这里的影响是：
         1.1 当Query的字段大小总和小于max_length_for_sort_data 而且排序字段不是 TEXT|BLOB 类型时，会用改进后的算法——单路排序， 否则用老算法——多路排序。
         1.2 两种算法的数据都有可能超出sort_buffer的容量，超出之后，会创建tmp文件进行合并排序，导致多次I/O，但是用单路排序算法的风险会更大一些,所以要提高sort_buffer_size。
     2. 尝试提高 sort_buffer_size
        不管用哪种算法，提高这个参数都会提高效率，当然，要根据系统的能力去提高，因为这个参数是针对每个进程的  1M-8M之间调整
     3. 尝试提高 max_length_for_sort_data
         提高这个参数， 会增加用改进算法的概率。但是如果设的太高，数据总容量超出sort_buffer_size的概率就增大，明显症状是高的磁盘I/O活动和低的处理器使用率.  1024-8096之间调整 

GROUP BY关键字优化

•   group by实质是先排序后进行分组，遵照索引建的最佳左前缀
•   当无法使用索引列，增大max_length_for_sort_data参数的设置+增大sort_buffer_size参数的设置
•   where高于having，能写在where限定的条件就不要去having限定了。 

 分页查询的优化---limit

 EXPLAIN    SELECT  SQL_NO_CACHE * FROM emp  ORDER  BY  deptid  LIMIT 10000,40

给deptno这个字段加上索引后：

 

没什么用。因为优化器认为limit的过滤效果并不好，所以放弃了使用索引过滤。 

优化：  先利用覆盖索引把要取的数据行的主键取到，然后再用这个主键列与数据表做关联：
EXPLAIN  SELECT  SQL_NO_CACHE * FROM emp INNER JOIN (SELECT id FROM emp e ORDER BY deptno LIMIT 10000,40) a ON a.id=emp.id
 

覆盖索引 --> 就是，select 到 from 之间查询的列 <=使用的索引列+主键