关于mysql索引:mysql索引不生效

36次阅读

共计 1781 个字符,预计需要花费 5 分钟才能阅读完成。

并不是索引越多越好,索引是一种以空间换取工夫的形式,所以建设索引是要耗费肯定的空间,况且在索引的保护上也会耗费资源。本文首发我的集体博客 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、索引散列值(反复多)不适宜建索引,例:性别、状态等字段不适宜。

不应该建设索引的字段规定

  1. 不应该在字段比拟长的字段上建设索引,因为会耗费大量的空间
  2. 对于频繁更新、插入的字段应该少建设索引,因为在批改和插入之后,数据库会去保护索引,会耗费资源
  3. 尽量少在无用字段上建设索引【where 条件中用不到的字段】
  4. 表记录太少不应该创立索引
  5. 数据反复且散布均匀的表字段不应该创立索引【选择性太低,例如性别、状态、虚实值等字段】
  6. 参加列计算的列不适宜建索引【放弃列 ” 洁净 ”,比方 from_unixtime(create_time) = ‘2014-05-29’ 就不能应用到索引,起因是 b + 树中存的都是数据表中的字段值,但进行检索时须要把所有元素都利用函数能力比拟,显然老本太大,所以语句应该写成 create_time = unix_timestamp(‘2014-05-29’)】

正文完
 0