mysqlunionall无法走索引11 27
创新互联建站专注于清江浦网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供清江浦营销型网站建设，清江浦网站制作、清江浦网页设计、清江浦网站官网定制、小程序开发服务，打造清江浦网络公司原创品牌,更为您提供清江浦网站排名全网营销落地服务。
1. like %%失效。 方案:改为like %,只写后面的%就能走索引。
2. 虽然有索引,但是查询条件没有索引列或者order by 排序没有索引列。 方案:让查询条件有索引列
3. 索引列存在null值的情况。 方案:索引列如果没有值,则给空字符串或者数字的0,总之就是不要设置null
MySQL索引失效的几种情况
1.索引不存储null值
更准确的说，单列索引不存储null值，复合索引不存储全为null的值。索引不能存储Null，所以对这列采用is null条件时，因为索引上根本
没Null值，不能利用到索引，只能全表扫描。
为什么索引列不能存Null值？
将索引列值进行建树，其中必然涉及到诸多的比较操作。Null值的特殊性就在于参与的运算大多取值为null。
这样的话，null值实际上是不能参与进建索引的过程。也就是说，null值不会像其他取值一样出现在索引树的叶子节点上。
2.不适合键值较少的列（重复数据较多的列）
假如索引列TYPE有5个键值，如果有1万条数据，那么 WHERE TYPE = 1将访问表中的2000个数据块。
再加上访问索引块，一共要访问大于200个的数据块。
如果全表扫描，假设10条数据一个数据块，那么只需访问1000个数据块，既然全表扫描访问的数据块
少一些，肯定就不会利用索引了。
3.前导模糊查询不能利用索引(like '%XX'或者like '%XX%')
假如有这样一列code的值为'AAA','AAB','BAA','BAB' ,如果where code like '%AB'条件，由于前面是
模糊的，所以不能利用索引的顺序，必须一个个去找，看是否满足条件。这样会导致全索引扫描或者全表扫
描。如果是这样的条件where code like 'A % '，就可以查找CODE中A开头的CODE的位置，当碰到B开头的
数据时，就可以停止查找了，因为后面的数据一定不满足要求。这样就可以利用索引了。
4.索引失效的几种情况
1.如果条件中有or，即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因)
要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引
2.对于多列索引，不是使用的第一部分，则不会使用索引
3.like查询以%开头
4.如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引
5.如果mysql估计使用全表扫描要比使用索引快,则不使用索引
5.MySQL主要提供2种方式的索引：B-Tree索引，Hash索引
B树索引具有范围查找和前缀查找的能力，对于有N节点的B树，检索一条记录的复杂度为O(LogN)。相当于二分查找。
哈希索引只能做等于查找，但是无论多大的Hash表，查找复杂度都是O(1)。
显然，如果值的差异性大，并且以等值查找（=、 、、in）为主，Hash索引是更高效的选择，它有O(1)的查找复杂度。
如果值的差异性相对较差，并且以范围查找为主，B树是更好的选择，它支持范围查找。
这个问题涉及到“覆盖索引”这个概念。你第一个查询是查count(*)，实际上值需要使用索引test，就能完全得到结果，不需要回聚簇索引查其他字段，因此InnoDB认为用这个所以比全表扫描快。
而第二个查询因为要访问iMoney，需要“回表”，用不上覆盖索引。
另外一个原因是索引字段的顺序，如果你把 test定义为(iType, dtEventTime)， 这个查询应该就能用上test这个索引。而现在字段顺序会导致你这个查询，即使要用这个索引，也只能用到第一个字段。
作为一名程序员，在求职面试时，不知你有没有遇到类似这样的问题。
张工是一名java程序员，最近到一家软件公司应聘软件开发岗位，面试官问了他关于MySql索引这样的一个问题。
对于这个问题张工之前在做项目时也曾遇到，那时候字段明明是加了索引，可不明白为什么还是很慢。后加上引号就正常了，为了赶项目进度，张工也没有再去留意。
现在面试官突然这么一问，张工也说不出个所以然来。
面试官让他回去等通知。
我们知道MySql索引可以加快数据检索速度，这也是使用的索引的最主要原因。但有时候使用不当就会遇到索引失效问题，譬如在MySQL字符串类型查询时不加引号索引会失效，是因为MySQL内部进行了隐式转换。
那为什么会发生隐式转换？又是怎么转换的呢？
今天我们来聊聊关于MySql索引失效的话题。
先来看看一般导致索引失效的有哪些？
如果一张表的索引有多个，要遵守最佳左前缀法则，即查询从索引的最左前列开始并且不跳过索引中的列。
用户表tb_user字段 id，name，age，sex
创建索引为idx_user_name
执行语句：
这时候就会导致索引失效
在索引列上做加工操作，查询时会导致索引失效，从而导致全表扫描。所以，建议不要在索引列上做任何操作。
举个例子，例如订单表tb_order有个索引是dt（日期）， 字段数据存放的格式是这样的2021-12-10 这样的，如果有个需求需要根据dt，格式是20220207这样的来查询，这时候就不要对dt进行格式转换了，
这样索引就失效了。
而是应该对 20220207做格式处理
这样dt索引才不会失效。
例如我们在订单表tb_order建立了索引idx_order_id，order_id字段类型为varchar
在查询时如果使用where order_id= 20220207123654100，这样的查询方式会直接造成索引失效。
要让索引生效，正确的用法为
假如有张用户表tb_user，创建的索引为idx_user_name_age_sex_phone 其中name、age、sex都加了索引。
执行语句
上面这条sql语句只会命中name和age索引，sex索引会失效，复合索引失效需要查看key_len的长度。
再来看一个例子：
从这两条SQL执行的结果我们可以看出，执行第一条SQL没有使用到索引，而执行第二条SQL时使用到了索引。这是为什么呢？
我们需要先了解下mysql索引优化器工作的原理。选择索引是优化器工作，优化器工作有自己的一套规则，如果等号两边的数据类型不一致，则会发生隐式转换。
基于这条规则，我们回过头看看
这条SQL语句执行时就会变为
由于对索引列进行了函数操作，所以才导致索引失效，从而全表扫描了。
那么问题来了，细心的你不知有没有留意到为什么是把左侧的列转为int类型，而不是把右侧的值转成字符串类型呢？
什么情况下把数字转为字符串，什么情况下把字符串转为数字，优化器它是根据什么规则来进行判断的？其实规则也并不复杂。
根据这个规则，我们再回过头看看之前的查询语句
select '12345678936' = 12345678936
返回1 所以这时候就把左侧的列值12345678936转成数字。
关于MySql索引失效的问题先简单写到这，建议平时在做项目时还是要多了解下原理，如果你了解其背后的原理，求职面试时和面试官交流起来就会很舒服了，相信能为这次面试加分，提高被录用的概率。
为什么MySQL字符串类型查询时不加引号索引会失效？这是因为要查询的字符串字段没有加引号时，MySQL内部进行了隐式转换，此次查询会导致全表扫描，所以慢了。
总结：
在索引列上进行了函数操作，MySQL内部会进行了隐式转换，导致索引失效，从而产生全表扫描。
由于笔者知识及水平有限,文中错漏之处在所难免,如有不足之处，欢迎交流。
拓展
索引创建
1、主键索引：
2、唯一索引：
3、普通索引：
4、全文索引：
alter table table_name add fulltext (column)
5、联合索引：
索引删除
