本文参考下面的文章:
2: Mysql语句的执行过程
3: sql优化的几种方法
我将 sql语句优化分为三个方面,(此处不包括 业务逻辑的优化 和 缓存的使用 ) : 索引优化 ; 关键字的使用 ; 有效的规避 .
1: 索引的优化 可以分为 索引命中无效 的 优化 和 索引命中低效 的 优化 ;
1) : 索引命中无效的情况:
a : 如果是单列索引的话;最好不要出现null ; 据说是允许为null的话,可能会得到不符合预期的结果集;
b: 索引前导模糊 如: like"%xx";
c: 负向条件查询 无法使用索引: 优化策略: 将负向条件优化为 in 查询 ; 负向条件有: != , <> , not in , not exists , not like ;
d: 索引列 参与 计算 ;
e: 索引列 做强制转换处理 ;
2) : 索引命中低效的情况:
a : 从效率上将: union > in > or ; 建议用 in ;
b : 联合索引最左前缀原则 ;
c: 对于 order by 要利用索引的有效性:
2: 关键字的使用:
a : 用 exists 优化 in ; (呃 , 这里我有个小疑问 , 上面说 将负面向条件查询 优化成 in 以及 将 union , or 也优化成 in ; 这里说 用 exists 来优化 in ; 那么问题来了, 要不要 将上面用到in的地方 也使用 exists 优化一下呢? )
b : 用 instr() 函数 优化 like ;
instr(a , b ) > 0 <==> 从 a列中 查找 like("%b%") ;
instr(a , b ) = 0 <==> 从 a列中 查找 not like("%b%") ;
instr(a , b ) = 1 <==> 从 a列中 查找 like("b%") ;
c : 超过三个表最好不要 join。
需要 join 的字段，数据类型必须一致，多表关联查询时，保证被关联的字段需要有索引
3 : 有效的规避 :
a: * 的使用;
尽量使用所有的列名,而不是* ;
b: union 与 union all
如果确定 使用 union 也不会产生 重复的记录 ; 那就使用 union ; union 效率要高于 union all
c: 如果明确知道只有一条结果返回，limit 1 能够提高效率。
d: 使用延迟关联
e: 尽量使用数字型字段:
