共计 1596 个字符,预计需要花费 4 分钟才能阅读完成。
本文次要针对 sql 索引优化做出实际验证
一、常见的语句优化
这里不做多的论述,因为都是些惯例的索引优化伎俩,想必大家都很分明以及确定如何应用
1.like 最左匹配准则
2. 用 exists 和 not exists 代替 in 和 not in
3.union all 代替 or
4. 不要在索引列上做任何操作,比方计算、函数、类型转换等,会导致索引生效
5. 尽量避免应用 select *
6. 能用 between and 不必 in
7. 尽量用 >= 代替 >
二、联结索引的应用
现有表 mat_order 订单表,联结索引由 (rphone
, order_id
, money
) 组成
针对这个联结索引,咱们测试一下,什么状况下会走索引,这里对 explain 的应用以及字段阐明不做过多解释,大家能够自行百度
1. 单个字段查问
explain select * from mat_order where order_id like ‘20200804141149%’;
explain select * from mat_order where rphone like ‘1862%’;
explain select * from mat_order where money > 20000;
以上 explain 后果得悉,只有第一个 sql 的 order_id 查问走了索引,与预期的统一,因为 mysql 的最左匹配准则,所以只有 order_id 的查问会走索引
2. 多个字段查问
这里用到联结索引的笼罩索引
explain select * from mat_order where rphone like ‘1862%’ and order_id like ‘20200804141149%’;
能够看到这里用了 rphone 和 order_id 的组合索引
explain select * from mat_order where order_id like ‘20200804141149%’ and rphone like ‘1862%’;
将 rphone 和 order_id 的程序调整,仍然会走 rphone 和 order_id 的组合索引
explain select * from mat_order where order_id like ‘20200804141149%’ and money > 20000;
如果只有 order_id 和 money 字段查问,则不会走索引,根据最左准则,匹配不到
explain select * from mat_order where rphone like ‘1862%’ and money > 20000;
这个 sql 仍然走了索引,但只是走了 rphone 的单列索引,通过 ken_len 的长度能够判断出,与走单个 rphone 索引的 ken_度统一,并没有走 rphone 和 money 的组合索引
explain select * from mat_order where rphone like ‘1862%’ and money > 20000 and order_id like ‘20200804141149%’;
组合的所有列都在 where 语句中,会走全组合索引,效率也是最高的
三、mysql 查问数据 30% 的设置
mysql 外部有设置,当咱们的 sql 查问出的数据大于 30% 时,即便 sql 语句满足索引的条件,仍然不会走索引,会进行全表扫描
explain select * from mat_order where rphone like ‘1862%’;
explain select * from mat_order where rphone like ‘186%’;
以上两个一样的 sql, 只因查问条件值不一样,一个走索引,一个全表扫描,因为第二个 sql 查问出的数据大于全表数据的 30%,则走索引的效率还不如全表扫描,则索引会生效
四、总结
1.sql 是否会走索引,除了 sql 自身合乎索引规定外,还须要看查问的数量占全表数据比,大于 30% 则不会走索引
2. 联结索引的查问,只有 where 条件前面的语句是联结索引笼罩到的,则都会走索引,与 where 条件的程序无关,因为执行器会优化