mysql怎么没有索引字 mysql 显示索引

阿里四面：为何MySQL没有使用建立的索引？

MySQL选了个不恰当索引而导致的慢查询。

某晚收到了线上数据库的频繁报警，数据库突然大量慢查询，导致每个数据库连接执行一个慢查询都要耗费很久。这还导致突然过来的很多查询需要让MySQL开辟更多连接，因此报警也告诉我们，数据库的连接剧增，而且每个连接都打满，每个连接都要执行一个慢查询。

接着DB的连接全部打满，无法开辟新连接，但还持续的有新的查询请求，导致DB无法处理新查询，很多查询发到DB直接就阻塞然后超时，导致商品系统频繁的报警，出现大量DB查询超时报错的异常。

这意味着商品数据库及商品系统濒临崩溃，大量慢查询耗尽DB连接资源，而且一直阻塞在数据库里执行，数据库没法执行新的查询，商品数据库无法执行查询，用户没法使用商品系统，也就没法查询和筛选电商网站里的商品了。

报警时机又正是晚高峰，虽说商品数据有多级缓存架构，但下单过程中，还是会大量请求商品系统，所以晚高峰时，商品系统本身TPS大致几千。因此发现数据库的监控里显示每min的慢查询超过10w+：商品系统大量的查询都变成了慢查询。

慢查询主要就是如下语句：

该语句执行的商品表里大致1亿左右数据量，该量级已稳定很长时间，主要也就是这么多商品，但上面语句居然一执行就是几十s！基本上数据库的连接全部被慢查询打满，一个连接要执行几十s的SQL，然后才能执行下一个SQL，此时数据库基本就废了，没法执行什么查询。所以商品系统本身也报警查询数据库的超时异常。

经常用到的查询字段肯定都建了索引，即index_category(catetory,sub_category)肯定存在。因为如果你一旦用上了品类索引，按品类和子类去在索引里筛选：

理论上执行速度很快，即使表有亿级数据，但也不应超过1s。但跑了几十秒，说明肯定没用那个索引，看执行计划：

possible_keys=index_category的，key=PRIMARY，Extra=Using where

就是在扫描主键索引，还用where条件里的两个字段做筛选，所以这么扫描就会耗费几十s。

为快速解决问题，使用force index语法，强制改变MySQL自动选择不恰当聚簇索引进行扫描的行为：

再次执行SQL，仅耗费100多ms。

所以若MySQL使用了错误的执行计划，那就force index语法改变它。

但案例还有问题：

该表是个亿级数据量大表，那index_category二级索引也比较大，所以此时MySQL觉得如果从index_category二级索引查找符合where条件的一波数据，接着还得回表。因为要select *，所以必然涉及回表，但在回表前，必然要做完order by id desc limit xx,xx操作。

举个例子，根据where category='xx' and sub_category='xx'，从index_category二级索引里查找出一波数据，假设几万条，

因为二级索引包含主键id，就得按order by id desc，对这几万条数据基于临时磁盘文件进行filesort磁盘排序，排序后，再按limit xx,xx语法将指定位置的几条数据拿出来，假设limit 0,10，那么就是把10条数据拿出来。拿出来10条数据之后，再回到聚簇索引根据id查，把这10条数据的完整字段都查出来，这就是MySQL认为如果你使用index_category的话，可能会发生的一个情况。

所以他担心，你根据

从index_category二级索引里查出来的数据太多了，还得在临时磁盘里排序，可能性能很差，因此MySQL就把这种方式判定不太好。

因此他选择直接扫描主键的聚簇索引，因为聚簇索引按id值有序，所以扫描时，直接按order by id desc倒序得顺序扫描即可，然后因为他知道你是

也就知道你仅仅只要拿到10条数据就行了。所以他在按序扫描聚簇索引时，就会对每条数据都采用Using where，跟

条件进行比对，符合条件的就直接放入结果集里去，最多就是放10条数据进去就可以返回了。

此时MySQL认为，按顺序扫描聚簇索引，拿到10条符合where条件的数据，应该很快，很可能比使用index_category二级索引更快，因此此时他就采用了扫描聚簇索引的这种方式。

这SQL之前在线上系统运行一直没问题，即之前在线上系统而言，即使采用扫描聚簇索引，该SQL也确实运行不慢，最起码是不会超过1s。

为何突然大量报慢查询，耗时几十s？因为之前

条件通常有返回值，即根据条件里的取值，扫描聚簇索引，通常都是很快就能找到符合条件的值并返回，所以之前其实性能也没啥问题。

但后来可能是商品系统里的运营人员，在商品管理的时候加了几种商品分类和子类，但是这几种分类和子类的组合其实没有对应的商品，导致很多用户使用这种分类和子类去筛选商品

条件实际上是查不到任何数据的！所以扫描聚簇索引时，怎么都扫不到符合条件的结果，一下就把聚簇索引全部扫了一遍，等于上亿数据全表扫描一遍，都没找到符合where category='新分类' and sub_category='新子类'这个条件的数据。

正因如此，才导致这个SQL语句频繁的出现几十秒的慢查询，进而导致MySQL连接资源打满，商品系统崩溃！

SQL调优并不太难，核心是看懂SQL执行计划，理解慢的原因，然后想法解决，本案例就得通过force index语法来强制某个SQL用我们指定的索引。

相关问答

Q1: mysql 查询id 怎么没有用上索引

合理使用索引，Cardinality是一个重要指标，太小的话跟没建没区别，还浪费空间。

如果你source字段是一个unique，就会用到索引。

如果你一定要用索引，可以用force index，不过效率不会有改善一般还会更慢就是了。

Q2: mysql中查询是为什么索引字段没有使用到

这个问题涉及到“覆盖索引”这个概念。你第一个查询是查count(*)，实际上值需要使用索引test，就能完全得到结果，不需要回聚簇索引查其他字段，因此InnoDB认为用这个所以比全表扫描快。

而第二个查询因为要访问iMoney，需要“回表”，用不上覆盖索引。

另外一个原因是索引字段的顺序，如果你把 test定义为(iType, dtEventTime)， 这个查询应该就能用上test这个索引。而现在字段顺序会导致你这个查询，即使要用这个索引，也只能用到第一个字段。

Q3: mysql如何建立索引

mysql怎么没有索引字我们可以通过查看索引mysql怎么没有索引字的属性来判断创建索引mysql怎么没有索引字的方法。

查看索引的语法格式如下mysql怎么没有索引字：

SHOW INDEX FROM 表名 [ FROM 数据库名]

语法说明如下：

表名：指定需要查看索引的数据表名。

数据库名：指定需要查看索引的数据表所在的数据库mysql怎么没有索引字，可省略。比如，SHOW INDEX FROM student FROM test; 语句表示查看 test 数据库中 student 数据表的索引。

示例

使用 SHOW INDEX 语句查看《MySQL创建索引》一节中 tb_stu_info2 数据表的索引信息，SQL 语句和运行结果如下所示。

mysql SHOW INDEX FROM tb_stu_info2\G

1. row

Table: tb_stu_info2

Non_unique: 0

Key_name: height

Seq_in_index: 1

Column_name: height

Collation: A

Cardinality: 0

Sub_part: NULL

Packed: NULL

Null: YES

Index_type: BTREE

Comment:

Index_comment:

1 row in set (0.03 sec)

其中各主要参数说明如下：

参数 说明

Table 表示创建索引的数据表名，这里是 tb_stu_info2 数据表。

Non_unique 表示该索引是否是唯一索引。若不是唯一索引，则该列的值为 1；若是唯一索引，则该列的值为 0。

Key_name 表示索引的名称。

Seq_in_index 表示该列在索引中的位置，如果索引是单列的，则该列的值为 1；如果索引是组合索引，则该列的值为每列在索引定义中的顺序。

Column_name 表示定义索引的列字段。

Collation 表示列以何种顺序存储在索引中。在 MySQL 中，升序显示值“A”（升序），若显示为 NULL，则表示无分类。

Cardinality 索引中唯一值数目的估计值。基数根据被存储为整数的统计数据计数，所以即使对于小型表，该值也没有必要是精确的。基数越大，当进行联合时，MySQL 使用该索引的机会就越大。

Sub_part 表示列中被编入索引的字符的数量。若列只是部分被编入索引，则该列的值为被编入索引的字符的数目；若整列被编入索引，则该列的值为 NULL。

Packed 指示关键字如何被压缩。若没有被压缩，值为 NULL。

Null 用于显示索引列中是否包含 NULL。若列含有 NULL，该列的值为 YES。若没有，则该列的值为 NO。

Index_type 显示索引使用的类型和方法（BTREE、FULLTEXT、HASH、RTREE）。

Comment 显示评注。

Q4: mysql 索引失效总结

首先我们还是先把表结构说下mysql怎么没有索引字：用户表tb_user结构如下：

1、 不要在索引列上进行运算操作mysql怎么没有索引字， 索引将失效。

手机号phone字段有唯一索引mysql怎么没有索引字，当根据phone字段进行函数运算操作之后mysql怎么没有索引字，索引失效:

2、 字符串类型字段使用时，不加引号，索引将失效。

如果字符串不加单引号，对于查询结果，没什么影响，但是数 据库存在隐式类型转换，索引将失效。

3、 如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效。

接下来，我们来看一下这三条SQL语句的执行效果，查看一下其执行计划：

由于下面查询语句中，都是根据profession（专业）字段查询，profession字段是一个普通的索引， 我们主要看一下，模糊查询时，%加在关键字之前，和加在关键字之后的影响。

经过上述的测试，我们发现，在like模糊查询中，在关键字后面加%，索引可以生效。而如果在关键字 前面加mysql怎么没有索引字了%，索引将会失效。

4、 用or分割开的条件， 如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会 被用到。

由于age没有索引，所以即使id有索引，索引也会失效。所以需要针对于age也要建立索引。

5、 数据分布影响：如果MySQL评估使用索引比全表更慢，则不使用索引。

Q5: mysql 这条查询语句怎么优化或建立哪些索引 执行结果只有A表没有用到索引

假如你有一个表，

SQL CREATE TABLE test_tab (

2 id INT,

3 name VARCHAR(10),

4 age INT,

5 val VARCHAR(10)

6 );

你的业务，有一个查询，是

SELECT * FROM test_tab WHERE name = 一个外部输入的数据

刚开始，数据不多的时候，执行效果还不错。

随着数据量的增加，这个查询，执行起来，越来越慢了。

然后在 name 上面 建立了索引

CREATE INDEX idx_test4_name ON test_tab (name );

这样， 可以加快前面那个查询的速度。

但是，某天，你执行了下面这个SQL， 发现速度又慢了

SELECT * FROM test_tab WHERE age = 25

为啥呢？ 因为 age 字段上面，没有索引

索引只在 name 上面有

换句话说， 也就是 WHERE 里面的条件， 会自动判断，有没有 可用的索引，如果有， 该不该用。

多列索引，就是一个索引，包含了2个字段。

例如：

CREATE INDEX idx_test_name_age ON test_tab (name, age);

那么

SELECT * FROM test_tab

WHERE

name LIKE '张%'

AND age = 25

这样的查询，将能够使用上面的索引。

多列索引，还有一个可用的情况就是， 某些情况下，可能查询，只访问索引就足够了， 不需要再访问表了。例如：

SELECT

AVG( avg ) AS 平均年龄

FROM

test_tab

WHERE

name LIKE '张%'

这个时候， name 与 age 都包含在索引里面。 查询不需要去检索表中的数据。

关于mysql怎么没有索引字和mysql 显示索引的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。