本文次要针对 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 条件的程序无关，因为执行器会优化