实操SQL优化

实操SQL优化

1. 可以走索引

1.1 应该走索引但是没走

联合索引的第一个字段不能过滤大部分数据，回表效率很低，甚至还说全表扫描的cost更小。

1.2 走索引了，但是不是最优，type要到range

强制走索引不可取

应该把*换成全是有索引的，也就是查询的列的字段全是有索引的，就不需要回表了。

1.3 分页不走索引

limit 10000，10；实质是取出10010条，再舍弃前10000条。

取巧，如果是主键索引，可以用where 筛选掉前10000条，但不通用。

二级索引真的强，select *的性能直逼全索引字段的

和普通的相比，强制索引也是还可以的

1.4 索引列上用了函数或者类型转换

给hire_time加了索引后

但只是有可能

1.5 根过滤的数据不多

根据查询条件过滤的数据不多，导致优化器认为走索引不如全表扫描。
比如is not null，这种能匹配到多条记录的写法。

1.6 order by 和 group by 优化

• 无条件查询如果只有order by create_time

  便create_time上有索引，也不会使用到。因为优化器认为走二级索引再去回表成本比全表扫描排序更高。所以选择走全表扫描，然后根据老师讲的两种方式选择一种来排序

• 无条件查询但是是order by create_time limit m。

  如果m值较小，是可以走索引的。因为优化器认为根据索引有序性去回表查数据，然后得到m条数据，就可以终止循环，那么成本比全表扫描小，则选择走二级索引。即便没有二级索引，mysql针对order by limit也做了优化，采用堆排序

MySQL 支持两种排序方式 filesort 和 index， Using index 是扫描索引完成的排序，而 Using filesort 是利用内存甚至磁盘完成排序的。因此，index 效率高，filesort 效率低。

2. 小表驱动大表

2.1 滴滴

3. count查询优化

count(*)是无所谓的，不会影响性能，MSQL 5.6+ 会对 count(*) 进行优化，所以执行效率还是很高的。