mysql 查询优化案例汇总

一 简介:此文章为经历过的sql案例集合和相关思路

二 案例1:

现象: 测试环境出现select语句,join2张表多次join,explain结果如下 出现 using where,using join buffer （Block Nested Loop)

思路分析:BNL 5.6优化,首先就看连接字段是否有索引(也有可能有索引没加上),发现没有索引

解决办法: 连接字段加上索引,问题解决(是不是很简单)

案例2

现象:线上出现select并发语句,语句比较复杂,就不贴出来了

思路分析:explain下发现多个join后面的连接字段没有索引

解决办法:连接字段加上索引,问题解决

案例3
    select * from a where ctime <= DATE_FORMAT(DATE_ADD(SYSDATE(), INTERVAL - 30 DAY), '%Y-%m-%d')  
    现象: 此语句全表扫描
    思路分析: 很奇怪的语句,ctime有索引,而且函数并没有作用于索引本身,为什么不走索引呢,尝试用字符串日期代替函数本身,explain下是走索引的,问题出现在函数这块
    解决办法: 将sysdate去掉,用now取代,explain下发现,已经走索引
   补充
    sysdate和now的区别
   1 select sysdate(),sleep(2),sysdate() select now(),sleep(2),now()
      SYSDATE获取当时实时的时间,在语句执行中是不断变化
      NOW()取的是语句开始执行的时间,在整个语句执行过程中都不会变化。
   2 sysdate在函数计算中不走索引,now可以走索引,前提这个时间字段本身是索引项

3 选择sysdate可能导致主从同步问题

建议 在mysql语句中建议采用now函数

案例 4

select * from  table  where  id  in ( id1 ,id 2,。。。）

现象  查询很慢,id存在索引,但是并没有走

思路分析:由于此表数据量大,可能存在因为数据量导致的索引失效问题,所以采用 force index进行尝试

解决办法: 采用force index方式进行查询

补充: explain下的force index出现了失真,扫描行数居然是表数据量的几倍,暂时没找到原因,所以,不要过分依赖explain的结果,自己去查询试试

案例5

select * from table where a='' order by b

现象 已经建立了 a和b的联合索引,依然出现了file sort文件排序

思路分析: 调出表结构发现 a varchar(200) b varchar(300)，远远超过了5.6规定的767字节,那为什么还能建立成功呢,原来5.7已经放开了限制,已经调大到3000+.但是依然只能用到前缀索引

解决办法: 缩短字段长度,尽量索引长度不要超过767字符

补充: 5.7虽然放开了索引长度的限制,但是毫无意义,也请大家尽量规范好字符串的长度,防止发生上述问题

案例6

select * from table where a= b= order by c

现象 已经建立了 a c 联合索引 ,但是效率很低

思路分析: 首先通过explain发现，扫描行数并不多 也就3W多行,但是令人奇怪的是,建立了a c联合的索引,却只用到了a,而且extra中并没有出现文件排序

解决方法: 建立 a b c三者的联合索引。

总结:不要单单看扫描行数少就认为不要优化,让sql走正确的索引,去掉不正确的,这也是一个非常重要的原则