AI 助理
备案控制台
开发者社区 数据库 文章 正文

如何用好MySQL的索引

2022-03-16 210
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
RDS MySQL Serverless 基础系列，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
RDS MySQL Serverless 高可用系列，价值2615元额度，1个月
云数据库 RDS PostgreSQL，高可用系列 2核4GB
简介： 你将会彻底理解索引覆盖和索引下推，索引失效的几个主要场景以及索引的创建和使用原则

我是蝉沐风。

这一篇文章来聊一聊如何用好MySQL索引。

image-20220316002210502

为了更好地进行解释，我创建了一个存储引擎为InnoDB的表user_innodb，并批量初始化了500W+条数据。包含主键id、姓名字段（name）、性别字段（gender，用0，1表示不同性别）、手机号字段（phone），并为name和phone字段创建了联合索引。

CREATE TABLE `user_innodb` (
  `id` int NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `gender` tinyint(1) DEFAULT NULL,
  `phone` varchar(11) DEFAULT NULL,
  PRIMARY KEY (`id`)，
  INDEX IDX_NAME_PHONE (name, phone)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

1. 索引的代价

索引可以非常有效地提升查询效率，既然这么好，我给每个字段都创建一个索引行不行？我劝你不要冲动。

4ebda2997c06dc9ae0dacef6f7a56e03

任何事情都有两面，索引也不例外。过度使用索引，我们在空间和时间上都会付出相应的代价。

1.1 空间上的代价

索引就是一棵B+数，每创建一个索引都需要创建一棵B+树，每一棵B+树的节点都是一个数据页，每一个数据页默认会占用16KB的磁盘空间，每一棵B+树又会包含许许多多的数据页。所以，大量创建索引，你的磁盘空间会被迅速消耗。

1.2 时间上的代价

空间上的代价你可以使用“钞能力”来解决，但时间上的代价我们可能就束手无策了。

链表的维护

我以主键索引为例举个例子，主键索引的B+树的每一个节点内的记录都是按照主键值由小到大的顺序，采用单向链表的方式进行连接的。如下图所示：

image-20220315103021926

如果我现在要删除主键id为1的记录，会破坏3个数据页内的记录排序，需要对这3个数据页内的记录进行重排列，插入和修改操作也是同理。

注：这里给大家提一嘴，其实删除操作并不会立即进行数据页内记录的重排列，而是会给被删除的记录打上一个删除的标识，等到合适的时候，再把记录从链表中移除，但是总归需要涉及到排序的维护，势必要消耗性能。

假如这张表有12个字段，我们为这张表的12个字段都设置了索引，我们删除1条记录，需要涉及到12棵B+树的N个数据页内记录的排序维护。

更糟糕的是，你增删改记录的时候，还可能会触发数据页的回收和分裂。还是以上图为例，假如我删除了id为13的记录，那么数据页124就没有存在的必要了，会被InnoDB存储引擎回收；我插入一条id为12的记录，如果数据页32的空间不足以存储该记录，InnoDB又需要进行页面分裂。我们不需要知道页面回收和页面分裂的细节，但是能够想象到这个操作会有多复杂。

如果每个字段都创建索引，所有这些索引的维护操作带来的性能损耗，你能想象了吧。

查询计划

执行查询语句之前，MySQL查询优化器会基于cost成本对一条查询语句进行优化，并生成一个执行计划。如果创建的索引太多，优化器会计算每个索引的搜索成本，导致在分析过程中耗时太多，最终影响查询语句的执行效率。

2. 回表的代价

2.1 什么是回表

我再啰嗦一遍什么是回表，我们可以通过二级索引找到B+树中的叶子结点，但是二级索引的叶子节点的内容并不全，只有索引列的值和主键值。我们需要拿着主键值再去聚簇索引（主键索引）的叶子节点中去拿到完整的用户记录，这个过程叫做回表。

image-20220313114610815

上图中我以name二级索引为例，并且只画出了二级索引的叶子节点和聚簇索引的叶子节点，省略了两棵B+树的非叶子节点。

从二级索引的叶子节点延伸出的3条线表示的就是回表操作。

2.2 回表的代价

我们根据name字段查找二级索引的叶子节点的代价还是比较小的，原因有二：

  1. 叶子节点所在的页通过双向链表进行关联，遍历的速度比较快；
  2. MySQL会尽量让同一个索引的叶子节点的数据页在磁盘空间中相邻，尽力避免随机IO。

但是二级索引叶子节点中的主键id的排布就没有任何规律了，毕竟name索引是对name字段进行排序的。进行回表的时候，极有可能出现主键id所在的记录在聚簇索引叶子节点中反复横跳的情况（正如上图中回表的3条线表示的那样），也就是随机IO。如果目标数据页恰好在内存中的话效果倒也不会太差，但如果不在内存中，还要从磁盘中加载一个数据页的内容（16KB）到内存中，这个速度可就太慢了。

是不是说完了回表的代价之后，我会给出一种更高效的搜索方式？不是，回表已经是一种比较高效的搜索方式了，我们需要做的就是尽量地减少回表操作带来的损耗，总结起来就是两点：

  1. 能不回表就不回；
  2. 必须回表就减少回表的次数。

接下来先给大家介绍两个与回表相关的重要概念，这两个概念涉及到的方法也是索引使用原则的一部分，因为比较重要，在这里我把这两个概念先解释给大家听。

3. 索引覆盖、索引下推

3.1 索引覆盖

想一下，如果非聚簇索引的叶子节点上有你想要的所有数据，是不是就不需要回表了呢？比如我为name和phone字段创建了一个联合索引，如下图：

image-20220313145021573

如果我们恰好只想搜索name、phone以及主键字段，

SELECT id, name,  phone FROM user_innodb WHERE name = "蝉沐风";

可以直接从叶子节点获取所有数据，根本不需要回表操作。

我们把索引中已经包含了所有需要读取的列数据的查询方式称为覆盖索引（或索引覆盖）。

3.2 索引下推

3.2.1 概念

还是拿name和phone的联合索引为例，我们要查询所有name为「蝉沐风」，并且手机尾号为6606的记录，查询SQL如下：

SELECT * FROM user_innodb WHERE name = "蝉沐风" AND phone LIKE "%6606";

由于联合索引的叶子节点的记录是先按照name字段排序，name字段相同的情况下再按照phone字段排序，因此把%加在phone字段前面的时候，是无法利用索引的顺序性来进行快速比较的，也就是说这条查询语句中只有name字段可以使用索引进行快速比较和过滤。正常情况下查询过程是这个样子的：

  1. InnoDB使用联合索引查出所有name为蝉沐风的二级索引数据，得到3个主键值：3485，78921，423476；
  2. 拿到主键索引进行回表，到聚簇索引中拿到这三条完整的用户记录；
  3. InnoDB把这3条完整的用户记录返回给MySQL的Server层，在Server层过滤出尾号为6606的用户。

如下面两幅图所示，第一幅图表示InnoDB通过3次回表拿到3条完整的用户记录，交给Server层；第二幅图表示Server层经过phone LIKE "%6606"条件的过滤之后找到符合搜索条件的记录，返给客户端。

存储引擎把数据给Server层

Server层返回过滤数据

值得我们关注的是，索引的使用是在存储引擎中进行的，而数据记录的比较是在Server层中进行的。现在我们把上述搜索考虑地极端一点，假如数据表中10万条记录都符合name='蝉沐风'的条件，而只有1条符合phone LIKE "%6606"条件，这就意味着，InnoDB需要将99999条无效的记录传输给Server层让其自己筛选，更严重的是，这99999条数据都是通过回表搜索出来的啊！关于回表的代价你已经知道了。

现在引入索引下推。准确来说，应该叫做索引条件下推（Index Condition Pushdown，ICP），就是过滤的动作由下层的存储引擎层通过使用索引来完成，而不需要上推到Server层进行处理。ICP是在MySQL5.6之后完善的功能。

再回顾一下，我们第一步已经通过name = "蝉沐风"在联合索引的叶子节点中找到了符合条件的3条记录，而且phone字段也恰好在联合索引的叶子节点的记录中。这个时候可以直接在联合索引的叶子节点中进行遍历，筛选出尾号为6606的记录，找到主键值为78921的记录，最后只需要进行1次回表操作即可找到符合全部条件的1条记录，返回给Server层。

很明显，使用ICP的方式能有效减少回表的次数。

另外，ICP是默认开启的，对于二级索引，只要能把条件甩给下面的存储引擎，存储引擎就会进行过滤，不需要我们干预。

3.2.2 演示

查看一下当前ICP的状态：

SHOW VARIABLES LIKE 'optimizer_switch';

image-20220314173759533

执行以下SQL语句，并用EXPLAIN查看一下执行计划，此时的执行计划是Using index condition

EXPLAIN SELECT * FROM user_innodb WHERE name = "蝉沐风" AND phone LIKE "%6606";

image-20220314174703523

然后关闭ICP

SET optimizer_switch="index_condition_pushdown=off";

再查看一下ICP的状态

image-20220314175214539

再次执行查询语句，并用EXPLAIN查看一下执行计划，此时的执行计划是Using where

EXPLAIN SELECT * FROM user_innodb WHERE name = "蝉沐风" AND phone LIKE "%6606";

image-20220314175324999

注：即使满足索引下推的使用条件，查询优化器也未必会使用索引下推，因为可能存在更高效的方式。

由于之前我给name字段创建了索引，导致一直没有使用索引下推，EXPLAIN语句显示使用了name索引，而不是name和phone的联合索引；删除name索引之后，才获得上述截图的效果。大家做实验的时候需要注意。

到目前为止大家应该清楚了索引和回表带来的性能问题，讲这些自然不是为了恐吓大家让大家远离索引，相反，我们要以正确的方式积极拥抱索引，最大限度降低其带来的负面影响，放大其优势。如何用好索引，从两个方面考虑：

  1. 高效发挥已经创建的索引的作用（避免索引失效）
  2. 为合适的列创建合适的索引（索引创建原则）

4. 什么时候索引会失效？

4.1 违反最左前缀原则

拿我们文章开始创建的联合索引为例，该联合索引的B+树数据页内的记录首先按照name字段进行排序，name字段相同的情况下，再按照phone字段进行排序。

所以，如果我们直接使用phone字段进行搜索，无法利用索引的顺序性。

EXPLAIN SELECT * FROM user_innodb WHERE phone = "13203398311";

image-20220315165212944

EXPLAIN可以查看搜索语句的执行计划，其中， possible_keys列表示在当前查询中，可能用到的索引有哪一些； key列表示实际用到的索引有哪一些。

但是一旦加上name的搜索条件，就会使用到联合索引，而且不需要在意name在WHERE子句中的位置，因为查询优化器会帮我们优化。

EXPLAIN SELECT * FROM user_innodb WHERE phone = "13203398311" AND name = '蝉沐风';

image-20220315165908904

4.2 使用反向查询（!=, <>,NOT LIKE）

MySQL在使用反向查询（!=, <>, NOT LIKE）的时候无法使用索引，会导致全表扫描，覆盖索引除外。

EXPLAIN SELECT * FROM user_innodb WHERE name != '蝉沐风';

image-20220315190829963

4.3 LIKE以通配符开头

当使用name LIKE '%沐风'或者name LIKE '%沐%'这两种方式都会使索引失效，因为联合索引的B+树数据页内的记录首先按照name字段进行排序，这两种搜索方式不在意name字段的开头是什么，自然就无法使用索引，只能通过全表扫描的方式进行查询。

EXPLAIN SELECT * FROM user_innodb WHERE name LIKE '%沐风';

image-20220315202339837

但是使用通配符结尾就没有问题

EXPLAIN SELECT * FROM user_innodb WHERE name LIKE '蝉沐%';

image-20220315202531736

4.4 对索引列做任何操作

如果不是单纯使用索引列，而是对索引列做了其他操作，例如数值计算、使用函数、（手动或自动）类型转换等操作，会导致索引失效。

4.4.1 使用函数

EXPLAIN SELECT * FROM user_innodb WHERE LEFT(name,3) = '蝉沐风';

image-20220315203446591

MySQL8.0新增了函数索引的功能，我们可以给函数作用之后的结果创建索引，使用以下语句

ALTER TABLE user_innodb ADD KEY IDX_NAME_LEFT ((left(name,3)));

再次执行EXPLAIN语句，此时索引生效

image-20220315204529598

4.4.2 使用表达式

EXPLAIN SELECT * FROM user_innodb WHERE id + 1 = 1100000;

image-20220315205336452

换一种方式，单独使用id，就能高效使用索引：

EXPLAIN SELECT * FROM user_innodb WHERE id = 1100000 - 1;

image-20220315205618100

4.4.3 使用类型转换

例1

user_innodb中的phone字段为varchar类型，实验之前我们先给phone字段创建个索引

ALTER TABLE user_innodb ADD INDEX IDX_PHONE (phone);

随便搜索一个存在的手机号，看一下索引是否成功

EXPLAIN SELECT * FROM user_innodb WHERE phone = '13203398311';

image-20220315211631637

可以看到能使用到索引，现在我们稍微修改一下，把phone = '13203398311'修改为phone = 13203398311，这意味着我们将字符串的搜索条件改成了整形的搜索条件，再看一下还会不会使用到索引：

EXPLAIN SELECT * FROM user_innodb WHERE phone = 13203398311;

image-20220315212929411

显示索引失效。

例2

我们再看一个例子，主键id类型是bigint，但是在搜索条件中我估计使用字符串类型：

EXPLAIN SELECT * FROM user_innodb WHERE id = '1099999';

image-20220315213426349

总结

稍微总结一下这个问题，当索引字段类型为字符串时，使用数字类型进行搜索不会用到索引；而索引字段类型为数字类型时，使用字符串类型进行搜索会使用到索引。

要搞明白这个问题，我们需要知道MySQL的数据类型转换规则是什么。简单地说就是MySQL会自动将数字转化为字符串，还是将字符串转化为数字。

一个简单的方法是，通过SELECT '10' > 9的结果来确定MySQL的类型转换规则：

  • 结果为1，说明MySQL会自动将字符串类型转化为数字，相当于执行了SELECT 10 > 9;
  • 结果为0，说明MySQL会自动将数字转化为字符串，相当于执行了SELECT '10' > '9'。
mysql> SELECT '10' > 9;
+----------+
| '10' > 9 |
+----------+
|        1 |
+----------+
1 row in set (0.00 sec)

上面的执行结果为1，说明MySQL遇到类型转换时，会自动将字符串转换为数字类型，因此对于例1:

EXPLAIN SELECT * FROM user_innodb WHERE phone = 13203398311;

就相当于

EXPLAIN SELECT * FROM user_innodb WHERE CAST(phone AS signed int) = 13203398311;

也就是对索引字段使用了函数，按照前文的介绍，对索引使用函数是不会使用到索引的。

对于例2:

EXPLAIN SELECT * FROM user_innodb WHERE id = '1099999';

就相当于

EXPLAIN SELECT * FROM user_innodb WHERE id = CAST('1099999' AS unsigned int);

没有在索引字段添加任何操作，因此能够使用到索引。

4.5 OR连接

使用OR连接的查询语句，如果OR之前的条件列是索引列，但是OR之后的条件列不是索引列，则不会使用索引。举例：

EXPLAIN SELECT * FROM user_innodb WHERE id = 1099999 OR gender = 0;

image-20220315225634020

上面总结了一些索引失效的场景，这些经验的总结往往对SQL的优化很有益处，但同时需要注意的是这些经验并非金科玉律。

比如使用<>查询时，在某些时候是可以用到索引的：

EXPLAIN SELECT * FROM user_innodb WHERE id <> 1099999;

image-20220315230633797

最终是否使用索引，完全取决于MySQL的优化器，而优化器的判定依据就是cost开销（Cost Base Optimizer），优化器并非基于具体的规则，也不是基于语义，就是单纯地执行开销小的方案罢了。所以在·EXPLAIN·的结果中你会看到possible_keys一列，优化器会把这里边的索引都试一遍（是不是又加深了对不能随便创建索引的认识呢？），然后选一个开销最小的，如果都不太行，那就直接全表扫描好了。

而cost开销，和数据库版本、数据量等都有关系，因此如果想更精准地提升索引功能性，拥抱EXPLAIN吧！

5. 索引创建（使用）原则

之前讲过的索引覆盖和索引下推都可以作为索引创建的原则，就是在创建索引的时候，尽量发挥索引覆盖和索引下推的优势。

尽量避免上述提及到的索引可能失效的情况的出现，同样是索引的使用原则。

除此之外，再给大家介绍一些。

5.1 不为离散度高的列创建索引

先来看一下列的离散度公式：COUNT(DISTINCT(column_name)) / COUNT(*)，列的不重复值的个数与所有数据行的比例。简而言之，如果列的重复值越多，列的离散度越低。重复值越少，离散度就越高。

举个例子，gender（性别）列只有0、1两个值，列的离散度非常低，假如我们为该列创建索引，我们会在二级索引中搜索到大量的重复数据，然后进行大量回表操作。大量回表哈？你懂了吧。

不要为重复值多的列创建索引

5.2 只为用于搜索、排序或分组的列创建索引

我们只为出现在WHERE子句中的列或者出现在ORDER BY和GROUP BY子句中的列创建索引即可。仅出现在查询列表中的列不需要创建索引。

5.3 用好联合索引

用2条SQL语句来说明这个问题：

1. SELECT * FROM user_innodb WHERE name = '蝉沐风' AND phone = '13203398311';
2. SELECT * FROM user_innodb WHERE name = '蝉沐风';

语句1和语句2都能够使用索引，这带给我们的一个索引设计原则就是：

不要为联合索引的第一个索引列单独创建索引

因为联合索引本身就是先按照name列进行排序，因此联合索引对name的搜索是有效的，不需要单独为name再创建索引了。也正因为此

建立联合索引的时候，一定要把最常用的列放在最左边

5.4 对过长的字段，建立前缀索引

如果一个字符串格式的列占用的空间比较大（就是说允许存储比较长的字符串数据），为该列创建索引，就意味着该列的数据会被完整地记录在每个数据页的每条记录中，会占用相当大的存储空间。

对此，我们可以为该列的前几个字符创建索引，也就是在二级索引的记录中只会保留字符串的前几个字符。比如我们可以为phone列创建索引，索引只保留手机号的前3位：

ALTER TABLE user_innodb ADD INDEX IDX_PHONE_3 (phone(3));

然后执行下面的SQL语句：

EXPLAIN SELECT * FROM user_innodb WHERE phone = '1320';

image-20220316000430252

由于在IDX_PHONE_3索引中只保留了手机号的前3位数字，所以我们只能定位到以132开头的二级索引记录，然后在遍历所有的这些二级索引记录时再判断它们是否满足第4位数为0的条件。

当列中存储的字符串包含的字符较多时，为该字段建立前缀索引可以有效节省磁盘空间

5.5 频繁更新的值，不要作为主键或索引

因为可能涉及到数据页分裂的情况，会影响性能。

5.6 随机无序的值，不建议作为索引，例如身份证、UUID

具体原因我在图解｜12张图解释MySQL主键查询为什么这么快文章中讲过，感兴趣可以阅读一下。

6. 推荐阅读

我是蝉沐风，如果你觉得这篇文章写得不错，请点赞和评论，你们的支持对我非常重要！我们下期见！

文章标签：
云数据库 RDS MySQL 版
SQL
关系型数据库
索引
MySQL
数据库
存储
关键词：
云数据库 RDS MySQL 版索引
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发，帮助IT从业者们通过“阿里云Web应用上云解决方案”，了解一个企业级Web应用上云的常见架构，了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品：云数据库RDS MySQL 版 阿里云关系型数据库RDS（Relational Database Service）是一种稳定可靠、可弹性伸缩的在线数据库服务，提供容灾、备份、恢复、迁移等方面的全套解决方案，彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
蝉沐风的码场
目录
相关文章
技术自由圈/原疯狂创客圈
|
2月前
|
存储 SQL 关系型数据库
mysql底层原理：索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog（图解+秒懂+史上最全）
mysql底层原理：索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog（图解+秒懂+史上最全）
技术自由圈/原疯狂创客圈
1052 0
mysql底层原理：索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog（图解+秒懂+史上最全）
小鎏学java
|
2月前
|
存储 关系型数据库 MySQL
MySQL数据库索引的数据结构？
MySQL中默认使用B+tree索引，它是一种多路平衡搜索树，具有树高较低、检索速度快的特点。所有数据存储在叶子节点，非叶子节点仅作索引，且叶子节点形成双向链表，便于区间查询。
小鎏学java
98 4
技术自由圈/原疯狂创客圈
|
4月前
|
存储 关系型数据库 MySQL
阿里面试：MySQL 一个表最多 加几个索引？ 6个？64个？还是多少？
阿里面试：MySQL 一个表最多 加几个索引？ 6个？64个？还是多少？
技术自由圈/原疯狂创客圈
1220 3
阿里面试：MySQL 一个表最多 加几个索引？ 6个？64个？还是多少？
游客bhmgxanbwhyfe
|
6月前
|
关系型数据库 MySQL 数据库
Mysql的索引
MYSQL索引主要有 : 单列索引 , 组合索引和空间索引 , 用的比较多的就是单列索引和组合索引 , 空间索引我这边没有用到过 单列索引 : 在MYSQL数据库表的某一列上面创建的索引叫单列索引 , 单列索引又分为 ● 普通索引：MySQL中基本索引类型，没有什么限制，允许在定义索引的列中插入重复值和空值，纯粹为了查询数据更快一点。 ● 唯一索引：索引列中的值必须是唯一的，但是允许为空值 ● 主键索引：是一种特殊的唯一索引，不允许有空值 ● 全文索引： 只有在MyISAM引擎、InnoDB（5.6以后）上才能使⽤用，而且只能在CHAR,VARCHAR,TEXT类型字段上使⽤用全⽂文索引。
游客bhmgxanbwhyfe
128 10
Unfailed_realme
|
2月前
|
存储 SQL 关系型数据库
MySQL 核心知识与索引优化全解析
本文系统梳理了 MySQL 的核心知识与索引优化策略。在基础概念部分，阐述了 char 与 varchar 在存储方式和性能上的差异，以及事务的 ACID 特性、并发事务问题及对应的隔离级别（MySQL 默认 REPEATABLE READ）。 索引基础部分，详解了 InnoDB 默认的 B+tree 索引结构（多路平衡树、叶子节点存数据、双向链表支持区间查询），区分了聚簇索引（数据与索引共存，唯一）和二级索引（数据与索引分离，多个），解释了回表查询的概念及优化方法，并分析了 B+tree 作为索引结构的优势（树高低、效率稳、支持区间查询）。 索引优化部分，列出了索引创建的六大原则
Unfailed_realme
85 2
蓝易云
|
3月前
|
存储 关系型数据库 MySQL
MySQL覆盖索引解释
总之，覆盖索引就像是图书馆中那些使得搜索变得极为迅速和简单的工具，一旦正确使用，就会让你的数据库查询飞快而轻便。让数据检索就像是读者在图书目录中以最快速度找到所需信息一样简便。这样的效率和速度，让覆盖索引成为数据库优化师傅们手中的尚方宝剑，既能够提升性能，又能够保持系统的整洁高效。
蓝易云
117 9
蓝易云
|
4月前
|
机器学习/深度学习 关系型数据库 MySQL
对比MySQL全文索引与常规索引的互异性
现在，你或许明白了这两种索引的差异，但任何技术决策都不应仅仅基于理论之上。你可以创建你的数据库实验环境，尝试不同类型的索引，看看它们如何影响性能，感受它们真实的力量。只有这样，你才能熟悉它们，掌握什么时候使用全文索引，什么时候使用常规索引，以适应复杂多变的业务需求。
蓝易云
106 12
互联网课堂
|
9月前
|
SQL 关系型数据库 MySQL
深入解析MySQL的EXPLAIN：指标详解与索引优化
MySQL 中的 `EXPLAIN` 语句用于分析和优化 SQL 查询，帮助你了解查询优化器的执行计划。本文详细介绍了 `EXPLAIN` 输出的各项指标，如 `id`、`select_type`、`table`、`type`、`key` 等，并提供了如何利用这些指标优化索引结构和 SQL 语句的具体方法。通过实战案例，展示了如何通过创建合适索引和调整查询语句来提升查询性能。
互联网课堂
1847 10
阿里云开发者
|
8月前
|
存储 关系型数据库 MySQL
MySQL索引学习笔记
本文深入探讨了MySQL数据库中慢查询分析的关键概念和技术手段。
阿里云开发者
604 81
运营研究坊
|
5月前
|
SQL 存储 关系型数据库
MySQL选错索引了怎么办？
本文探讨了MySQL中因索引选择不当导致查询性能下降的问题。通过创建包含10万行数据的表并插入数据，分析了一条简单SQL语句在不同场景下的执行情况。实验表明，当数据频繁更新时，MySQL可能因统计信息不准确而选错索引，导致全表扫描。文章深入解析了优化器判断扫描行数的机制，指出基数统计误差是主要原因，并提供了通过`analyze table`重新统计索引信息的解决方法。
运营研究坊
137 3

热门文章

最新文章

  • 1
    从下载到运行：MySQL 详细安装配置完整教程
  • 2
    解决MySQL的sql_mode=only_full_group_by错误提示
  • 3
    MySQL数据库连接过多（Too many connections）错误处理策略
  • 4
    使用命令行cmd查询MySQL表结构信息技巧分享。
  • 5
    查寻MySQL或SQL Server的连接数，并配置超时时间和最大连接量
  • 6
    修复.net Framework4.x连接MYSQL时遇到utf8mb3字符集不支持错误方案。
  • 7
    安装与配置MySQL 8 on Ubuntu，包括权限授予、数据库备份及远程连接指南
  • 8
    深入理解MySQL索引类型及其应用场景分析。
  • 9
    MySQL入门指南：从安装到第一个查询
  • 10
    MySQL锁机制：并发控制与事务隔离
  • 1
    在 MySQL 中使用 Distinct
    1418
  • 2
    在 MySQL 中使用 IS NULL
    914
  • 3
    MySQL——增量备份和全量备份
    123
  • 4
    Mysql80 密码忘记了怎么办
    176
  • 5
    MySQL——如何查看MySQL登录日志
    863
  • 6
    MySQL——删除重复数据
    101
  • 7
    Go语言中进行MySQL预处理和SQL注入防护
    332
  • 8
    MySQL——查看当前数据库中所有库中表的行数
    79
  • 9
    MySQL——大量的deleted进程导致磁盘100%
    86
  • 10
    MySQL——查看数据库大小
    132

    • 相关课程

    更多
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 阿里云数据库产品家族及特性
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • MySQL 技术大全：开发、优化与运维实战
  • 阿里云数据库运维实战手册
  • 搭建电商项目架构连接MySQL

    • 推荐镜像

    更多
  • mysql
    • 下一篇
    2025云栖大会，阿里云百炼邀请您的参与和见证