用人名做网站域名,wordpress 手机不显示内容,济南建设银行公积金网站,息壤网站打不开了2.3.4. 索引失效
对索引使用左或者左右模糊匹配
使用左或者左右模糊匹配的时候#xff0c;也就是 like %xx 或者 like %xx% 这两种方式都会造成索引失效。但是如果前缀是确定的那么就可以使用到索引#xff0c;例如 name like 许%。
因为索引 B 树是按照「索引值」有序排列…2.3.4. 索引失效
对索引使用左或者左右模糊匹配
使用左或者左右模糊匹配的时候也就是 like %xx 或者 like %xx% 这两种方式都会造成索引失效。但是如果前缀是确定的那么就可以使用到索引例如 name like 许%。
因为索引 B 树是按照「索引值」有序排列存储的只能根据前缀进行比较。如果使用 name like %许 方式来查询查询的结果可能是「小许、大许、老许」等之类的存储引擎不知道从哪个索引值开始比较于是就只能通过全表扫描的方式来查询。
对索引使用函数
查询条件中对索引字段使用函数就会导致索引失效。因为索引保存的是索引字段的原始值而不是经过函数计算后的值自然就没办法走索引了。
MySQL 5.7 开始索引特性增加了函数索引即可以针对函数计算后的值建立一个索引也就是说该索引的值是函数计算后的值所以就可以通过扫描索引来查询数据。
-- 对 length(name) 的计算结果建立一个名为 idx_name_length 的索引。
alter table t_user add key idx_name_length ((length(name)));
对索引进行表达式计算
在查询条件中对索引进行表达式计算也是无法走索引的。例如下面代码
explain select * from t_user where id 1 10;
如果把查询语句的条件改成 where id 10 - 1这样就不是在索引字段进行表达式计算了于是就可以走索引查询了。
因为索引保存的是索引字段的原始值而不是 id 1 表达式计算后的值所以无法走索引只能通过把索引字段的取值都取出来然后依次进行表达式的计算来进行条件判断因此采用的就是全表扫描的方式。
个人觉得这种方式完全可以不使用没必要这么麻烦。
对索引隐式类型转换
索引字段是字符串类型查询条件种输入的参数是整型在执行计划里发现这条语句会走全表扫描。
索引字段是整型类型查询条件中的输入的参数是字符串不会导致索引失效还是可以走索引扫描。
-- 例1、索引是字符串 参数是整型
select * from t_user where phone 1300000001;
-- 例2、索引是整型 参数是字符串
select * from t_user where id 1;
因为MySQL 在遇到字符串和数字比较的时候会自动把字符串转为数字然后再进行比较。
-- 例1
select * from t_user where CAST(phone AS signed int) 1300000001;-- 例2
select * from t_user where id CAST(1 AS signed int);
例1CAST 函数是作用在了 phone 字段而 phone 字段是索引也就是对索引使用了函数
例2索引字段并没有用任何函数CAST 函数是用在了输入参数所以可以走索引扫描的。
组合索引非最左匹配
如果创建了一个 (a, b, c) 组合索引因为有查询优化器所以 a 字段在 where 子句的顺序并不重要。
如果查询条件是以下这几种因为不符合最左匹配原则所以就无法匹配上联合索引联合索引就会失效:
where b2where c3where b2 and c3
比较特殊的查询条件where a 1 and c 3 符合最左匹配吗
MySQL 5.5 的话前面 a 会走索引在联合索引找到主键值后开始回表到主键索引读取数据行Server 层从存储引擎层获取到数据行后然后在 Server 层再比对 c 字段的值。
从 MySQL 5.6 之后有一个索引下推功能可以在存储引擎层进行索引遍历过程中对索引中包含的字段先做判断直接过滤掉不满足条件的记录再返还给 Server 层从而减少回表次数。
在组合索引的情况下数据是按照索引第一列排序第一列数据相同时才会按照第二列排序。
如果我们想使用联合索引中尽可能多的列查询条件中的各个列必须是组合索引中从最左边开始连续的列。如果我们仅仅按照第二列搜索肯定无法走索引。
WHERE 子句中的 OR
在 WHERE 子句中如果在 OR 前的条件列是索引列而在 OR 后的条件列不是索引列那么索引会失效。只有一个条件列是索引列是没有意义的只要有条件列不是索引列就会进行全表扫描所以需要两个条件都是索引列。
