并不是索引越多越好，索引是一种以空间换取工夫的形式，所以建设索引是要耗费肯定的空间，况且在索引的保护上也会耗费资源。本文首发我的集体博客mysql索引不失效
这里有张用户浏览商品表，建表语句：
CREATE TABLE `product_view` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL, `product_id` int(11) NOT NULL, `server_id` int(11) NOT NULL, `duration` int(11) NOT NULL, `times` varchar(11) NOT NULL, `time` datetime NOT NULL, PRIMARY KEY (`id`), KEY `time` (`time`), KEY `user_product` (`user_id`,`product_id`) USING BTREE, KEY `times` (`times`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;能够看出目前这张表是有3个索引的：
我往这张表外面导入了10万多条记录。
mysql不走索引的状况
1、like查问以“%”结尾(如果结尾、后果都有“%”，也不会应用索引，走的是全表扫描)；
我这里用了列出了4种状况，发现都是全表扫描，不走索引的。可能因为times取值不够离散，索引没有走索引。
2、or语句前后没有同时应用索引;
首先看看or语句前后同时应用索引：
查问走索引了。
再看看or语句前后没有同时应用索引，product_id是索引字段，server_id不是索引字段：
是没有走索引的。
3、组合索引中不是应用第一列索引；（不合乎最左匹配准则）
这张表索引为工夫time和一个组合索引：
这里组合索引user_product，咱们先应用user_id这个第一列索引，作为查问条件，查看执行打算：
应用了索引。
接下来应用组合索引user_product的非第一列索引product_id，再看看执行打算：
没有应用索引。
4、where条件中类型为字符串的字段没有应用引号引起来；【查问where条件数据类型不匹配也无奈应用索引，字符串与数字比拟不应用索引，因为正则表达式不应用索引，如varchar不加单引号的话可能会主动转换为int型，使索引有效，产生全表扫描】
首先看看where后条件字符串失常应用引号：
应用了索引。
where后条件字符串不应用引号，而应用数字：
能够看到，查问没有走索引。
5、当全表扫描速度比索引速度快时，mysql会应用全表扫描，此时索引生效；(*数据量少*)
我把表数据删了，外面留了7条数据：
条件查问索引字段列times:
显然是没有走索引的。
6、在索引字段上应用“not”，“<>”，“!=”等等；
通过验证发现，应用这些符号后，仍然会走索引。
7、对索引字段进行计算操作、应用函数;
MySql 如果表中某个工夫字段（datetime/…）设置了索引，以函数 DATE_FORMAT() 为查问条件时，为datetime设置的索引不失效，会引起全表扫描导致查问很慢。
没有用函数时候是走了索引的，查出具体到时分秒的数据：
应用函数data_format函数，查出2020-08-14这一天的所有数据：
没有走索引，那么怎么解决呢？
如果肯定要用函数，比方date_format，能够通过这种形式，就会走索引。
8、索引散列值（反复多）不适宜建索引，例：性别、状态等字段不适宜。
不应该建设索引的字段规定
- 不应该在字段比拟长的字段上建设索引，因为会耗费大量的空间
- 对于频繁更新、插入的字段应该少建设索引，因为在批改和插入之后，数据库会去保护索引，会耗费资源
- 尽量少在无用字段上建设索引【where条件中用不到的字段】
- 表记录太少不应该创立索引
- 数据反复且散布均匀的表字段不应该创立索引【选择性太低，例如性别、状态、虚实值等字段】
- 参加列计算的列不适宜建索引【放弃列"洁净"，比方from_unixtime(create_time) = '2014-05-29'就不能应用到索引，起因是b+树中存的都是数据表中的字段值，但进行检索时须要把所有元素都利用函数能力比拟，显然老本太大，所以语句应该写成create_time = unix_timestamp('2014-05-29')】