mysql怎么会不走索引 mysql索引为什么不用跳表

Mysql - like 语句会不会走索引 答案是满足特定条件, 会,如下:
原因是满足 最左前缀
最左前缀不仅仅适用于 组合索引,还适用于 varchar 的 like 语句,但是要注意,只有 like "XXX%" 的情况走索引,like "%XXX" 是不走索引的 。
Mysql innodb 引擎默认的索引数据结构是 b+ 树,组合索引会形成多字段顺序排序,比如下图,会先按照姓名进行排序,姓名相等就再按照年龄排序,所以会有组合索引的最左前缀原理,而假如只 like 查询姓名,例如 like "张%" ,则也可以使用最左前缀原理 , 先索引到 张六 ,然后遍历查询,直到姓名不以 张 开头 。
="或"'>MySQL使用">="或"2020-02-27
最近一个日志页面查询很慢 , 然后去跟踪了查询sql,发现日期字段上即使建了索引,查询还是很慢 , 执行语句还是使用了全表扫描,于是继续分析下去 。
查询语句类似:
select * from logs where createtime = '2020-01-01' ;
起初因为date上没检索,查询执行的是全表扫描,给条件字段createtime建上索引:
再次执行:
查询执行的还是全表扫描:
网上查询有说是因为在查询数据条数约占总条数五分之一以下时能够使用到索引,但超过五分之一时 , 使用全表扫描 。于是把日期范围缩?。?
果真,查询执行的是range:
由此可知,在进行范围查询时 , 比如:、 、=、=等, 如果数据量过大的话 , 即使where条件字段已经建立了索引,查询语句执行时还是有可能进行全表扫描的 。
实际上是不是全表的五分之一以下才会使用索引,这个不能确定,以后再研究了 。
mysql根据索引去修改数据,会走索引吗不一定,要看情况,具体是由MySQL优化器内部决定是全表扫描还是索引查找 , 用效率较高的一种方式 。
针对索引字段的唯一性不高的情况下(索引的"区分度"低),优化器可能会选择全表扫描,而不是走索引 。这可能是因为等值查询符合条件的记录太多了,导致了mysql认为全表扫描比用索引查找更快 。
比如你对唯一性不高的字段(如性别:男/女)加了索引,这样通过索引去查找可能还需回表,还不如直接全表扫描!
若in中的数据量较大时,基本就不走索引了 。如果你索引字段是一个unique,in可能就会用到索引 。
如果你一定要用索引,可以用 force index 。可能也和MySQL版本有关(5.6以后有做in的查询优化)
mysql什么情况下不会使用索引1、如果MySQL估计使用索引比全表扫描更慢,则不适用索引,
ex:列key_part1均匀的分布在1-100之间 。下面的sql则不会使用索引
select * from table_name where key_part11 and key_part1 90
2、如果使用memory/heap表,并且where语句中不适用“=”进行索引 , 则不会使用索引 。heap表只有在“=”的条件下,才使用索引 。
3、用or分割开的条件,如果or左右两个条件中有一个列没有索引 , 则不会使用索引 。
ex:select * from table_name where key1='a' or key2='b';
如果在key1上有索引而在key2上没有索引,则该查询也不会走索引
4、复合索引,如果索引列不是复合索引的第一部分,则不使用索引(即不符合最左前缀)
ex:复合索引为(key1,key2) ,一下sql将不会使用索引
select * from table_name where key2='b';
5、如果like是以‘%’开始的,则该列上的索引不会被使用 。
ex:select * from table_name where key1 like '%a';
6.如果列为字符串 , 则where条件中必须将字符常量值加引号,否则即使该列上存在索引 , 也不会被使用 。

推荐阅读