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

谁借莪１个温暖的怀抱￠ 2024-02-19 13:28 18阅读 0赞

**索引的规则**：

1.索引失效情况

<1>**全值匹配我最爱**

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

建立索引前:

![2018111716105811.png][]

索引后：

![20181117161114908.png][]

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

EXPLAIN SELECT SQL\_NO\_CACHE \* FROM emp WHERE emp.age=30 AND emp.name = 'abcd'

![20181117161253467.png][]

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

![20181117161338347.png][]

完全没有使用上索引

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

<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'

第一种：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU0OTU3OA_size_16_color_FFFFFF_t_70][]

第二种：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU0OTU3OA_size_16_color_FFFFFF_t_70 1][]

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

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

![2018111716183567.png][]

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

![20181117161855494.png][]

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU0OTU3OA_size_16_color_FFFFFF_t_70 2][]

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU0OTU3OA_size_16_color_FFFFFF_t_70 3][]

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

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

总结：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU0OTU3OA_size_16_color_FFFFFF_t_70 4][]

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

![20181117163632270.png][]

修改：

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

![20181117163718224.png][]

**order by关键字优化**

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU0OTU3OA_size_16_color_FFFFFF_t_70 5][]

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

![20181117164040374.png][]

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

![20181117164406525.png][]

没什么用。因为优化器认为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  
![20181117164600264.png][]

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

[2018111716105811.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/29a9bc7b9b4f43e98f8ee581c5686566.png
[20181117161114908.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/6e8d4f9b6c2b426a859c1609b5c98ed5.png
[20181117161253467.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/debe749360014b878d03c558370edd3b.png
[20181117161338347.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/bf45c702fdf840ea9520fe0db91b73f2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU0OTU3OA_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/fec1c10dcd8b42b8b5c0d54a58d04b2c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU0OTU3OA_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/70f94b1f19ea46e1b8985c5134d58de5.png
[2018111716183567.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/046a6ff2201e48f4b45df13046b084c6.png
[20181117161855494.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/7bf6fe6181c7479d94a53be2e3b75d85.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU0OTU3OA_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/e1fda159a9264bbd97d14afce51d0717.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU0OTU3OA_size_16_color_FFFFFF_t_70 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/3b04b70662e84635afd4df143708c571.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU0OTU3OA_size_16_color_FFFFFF_t_70 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/67a95ed4f86f4a4ba0e0eb67fa1ac226.png
[20181117163632270.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/00ab93af8d67446e9c7a5744c567e93d.png
[20181117163718224.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/4cb10bc7b6554ab18898a80381cbfe47.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU0OTU3OA_size_16_color_FFFFFF_t_70 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/3d41df0b4b3544cd886b1a6439c3f216.png
[20181117164040374.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/02b56fa971bd4a85a437dac14c2e4a78.png
[20181117164406525.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/8e34e47d4ac542fa9f8ed7b424bd9172.png
[20181117164600264.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/83034d094f7749feb28cff4e817ebdb4.png