MySQL 索引实战详解：从创建到优化，彻底解决查询慢问题

MySQL 索引实战详解：从创建到优化，彻底解决查询慢问题

一、查询慢的"元凶"与索引的核心价值

1.1 实战痛点直击：查询慢引发的业务问题

做后端开发、DBA的同学，几乎都遇到过这样的场景：线上系统突然报警，接口响应超时，排查后发现是MySQL查询变慢------一张100万数据的订单表，查询某用户的订单要5秒以上；商品列表页加载卡顿，打开要3-4秒，用户频繁投诉；统计报表查询超时，后台任务执行失败，影响业务正常运转。

这些问题的核心影响远比"卡顿"更严重：用户体验下降会直接导致留存率降低，接口QPS上不去会限制系统并发能力，服务器负载过高可能引发连锁故障，甚至导致系统宕机。更让人头疼的是，很多开发者陷入"查询慢就加索引"的误区，结果加了索引之后，查询没快多少，反而导致插入、更新、删除操作变慢，得不偿失。

这里先给大家一个核心警示：不是所有查询慢都要加索引，也不是加了索引就一定快。索引是一把"双刃剑"，用对了能让查询速度提升10倍、100倍，用错了反而会拖慢整个系统。

1.2 本文核心价值：手把手搞定索引实战，彻底解决查询慢

本文不堆砌底层原理，不搞空洞的理论，全程聚焦"实战落地"，面向后端开发、DBA、测试工程师，不管你是刚接触MySQL的新手，还是有一定经验但经常踩坑的开发者，都能从中收获实用技能。

读完本文，你将掌握：索引的核心概念与常见类型，不同场景下索引的创建技巧（附可复制SQL），索引失效的高频场景与避坑方法，索引优化的实战技巧，以及查询慢问题的快速排查流程。全程配套真实业务案例，所有SQL均可直接复制到项目中使用，真正做到"看完就能用，用了就见效"。

1.3 开篇小结：索引的本质是"加速查询的数据集"

一句话讲透索引的核心：索引就像书的目录，我们想找到书中某一章节，不需要逐页翻找，通过目录就能快速定位到具体页码；MySQL索引也是一样，它是一种特殊的数据结构（主要是B+树），存储在磁盘上，关联表中的列，能帮助MySQL快速定位符合条件的数据，减少磁盘I/O次数，从而解决查询慢的核心痛点。

简单来说，索引的核心作用就是"减少数据扫描范围"，把原本需要扫描全表的查询，变成只扫描少量索引数据，进而提升查询速度。

二、小白也能看懂的MySQL索引核心概念

2.1 核心定义：索引到底是什么？（极简版）

很多新手觉得索引很高深，其实没必要过度纠结底层实现，我们只需要记住：MySQL索引是一种特殊的数据结构，主要以B+树的形式存储在磁盘上，它不存储完整的行数据，只存储表中某一列（或多列）的值，以及这些值对应的行数据的物理地址（或主键），用于快速定位符合条件的行，减少磁盘I/O操作，提升查询效率。

举个例子：一张user表，有id、name、phone三个字段，给phone列创建索引后，索引会单独存储所有phone的值，以及每个phone对应的id（主键），当我们执行"SELECT * FROM user WHERE phone='13800138000'"时，MySQL会先在索引中找到该phone值对应的id，再通过id找到完整的行数据，无需扫描整个user表。

2.2 索引的核心作用（实战导向，不搞虚的）

索引的作用主要有3个，全部围绕"实战"展开，没有多余的理论：

第一，加速查询：这是索引最核心的作用。没有索引时，MySQL会进行全表扫描，即逐行检查每一条数据，直到找到符合条件的记录，时间复杂度是O(n)，数据量越大，查询越慢；有了索引后，MySQL会通过索引快速定位数据，时间复杂度降低到O(log n)，百万级数据也能实现秒级查询。

第二，优化排序：当查询语句中包含ORDER BY、GROUP BY时，MySQL如果没有索引，会先查询出所有数据，再进行排序（即filesort），效率极低；如果有索引，因为索引本身是有序的，MySQL可以直接通过索引获取排序后的结果，避免filesort，提升排序效率。

第三，约束作用：主键索引和唯一索引可以实现数据唯一性约束。比如给phone列创建唯一索引，就能保证phone值不重复，避免出现重复的用户手机号；主键索引则能保证主键字段非空且唯一，避免出现重复的主键值。

2.3 常见索引类型（实战高频，重点区分）

MySQL的索引类型有很多，但实战中最常用的只有5种，我们重点区分它们的用途和使用场景，避免用错：

1. 主键索引（PRIMARY KEY）：默认唯一、非空，一张表只能有一个主键索引，主要用于加速主键查询。几乎所有表都必须有主键索引，比如user表的id、order表的order_id，优先使用自增主键（INT/BIGINT），这是最符合MySQL优化逻辑的主键类型。

2. 唯一索引（UNIQUE）：值唯一，允许为空（但空值只能有一个，因为MySQL中NULL != NULL），主要用于避免重复数据，同时加速查询。比如用户的phone、邮箱，订单的order_no，这些字段需要唯一，就适合创建唯一索引。

3. 普通索引（INDEX）：最常用、无任何约束，仅用于加速查询，没有唯一性要求。比如商品名称（goods_name）、用户昵称（nickname），这些字段经常用于查询，但不需要唯一，就适合创建普通索引。

4. 联合索引（复合索引）：多列组合创建的索引，遵循"最左前缀原则"，是实战中高频使用的进阶索引类型。比如订单表中，经常需要"查询某用户某时间段的订单"，就可以创建联合索引（user_id, create_time），适配这类高频查询场景。

5. 全文索引（FULLTEXT）：专门用于文本搜索，比如文章内容、商品描述，能高效处理模糊搜索，避免使用"like %xxx%"导致的全表扫描。需要注意的是，全文索引只支持CHAR、VARCHAR、TEXT类型的字段，且MyISAM和InnoDB引擎都支持（InnoDB从MySQL 5.6开始支持）。

2.4 关键误区：这些索引认知一定要避开

新手学习索引，很容易陷入以下3个误区，尤其是前两个，几乎每个开发者都踩过坑，一定要重点避开：

误区1：索引越多越好。很多人觉得"多建索引，查询就会更快"，其实不然。索引虽然能加速查询，但会增加写入、更新、删除操作的开销------每次执行insert、update、delete时，MySQL不仅要修改表数据，还要同步修改所有相关的索引，索引越多，这些操作越慢。一般来说，单表索引不超过5个，够用即可。

误区2：加了索引就一定快。索引不是"万能的"，如果索引设计不合理、查询语句不规范，索引会失效，此时查询不仅不会变快，反而可能更慢（因为MySQL要先扫描索引，再扫描全表，相当于多做了一步操作）。

误区3：所有查询都要加索引。对于小表（数据量<10万条），全表扫描的速度比索引扫描更快------因为索引本身也需要占用磁盘空间，MySQL读取索引再定位数据，反而不如直接扫描全表高效。比如一张只有几千条数据的字典表，就没必要创建索引。

三、核心实战：MySQL索引创建技巧（按场景分类，可直接套用）

3.1 索引创建的核心原则（实战准则，记牢少踩坑）

创建索引不是"想建就建"，遵循以下4个核心原则，能让你少踩80%的坑，同时保证索引的高效性：

1. 高频查询列优先：where、order by、group by中频繁出现的列，优先创建索引。比如订单表中，user_id、create_time经常出现在where和order by中，就适合创建索引；而那些很少用于查询的列（如备注字段），就没必要创建索引。

2. 区分度高的列优先：列的唯一值越多（区分度越高），索引效果越好。比如身份证号（几乎每个值都唯一）>手机号（大部分唯一）>性别（只有男、女、未知三个值），性别列区分度极低，单独创建索引几乎没有意义。

3. 避免冗余索引：如果创建了联合索引（a,b），就无需再单独创建索引（a）------因为联合索引（a,b）本身就包含了a列的索引，再创建单独的a列索引，就是冗余索引，只会增加维护开销，没有任何好处。

4. 控制索引数量：单表索引不超过5个，避免写入操作性能下降。如果一张表的索引过多，每次写入数据时，MySQL需要同步更新所有索引，会严重影响写入速度。

3.2 单表索引创建实战（最常用场景）

单表索引是实战中最基础、最常用的索引类型，我们按场景分类，给出可直接复制的SQL示例，新手也能轻松上手。

3.2.1 普通索引创建（高频查询列）

适用场景：商品列表查询（根据商品名称查询）、用户列表查询（根据昵称查询）、文章列表查询（根据标题查询）等，这类场景中，查询列频繁出现，但不需要唯一约束。

SQL示例（可直接复制）：

-- 商品表：给商品名称创建普通索引
CREATE INDEX idx_goods_name ON goods(name);

-- 用户表：给用户昵称创建普通索引
CREATE INDEX idx_user_nickname ON user(nickname);

-- 文章表：给文章标题创建普通索引（长文本截取前缀，避免开销过大）
CREATE INDEX idx_article_title ON article(title(20));

注意事项：避免对长文本列（如varchar(255)、text）创建完整的普通索引，因为长文本索引会占用大量磁盘空间，且查询效率不高。可以截取前缀创建索引，比如标题截取前20个字符，既能保证索引效果，又能减少磁盘开销。

3.2.2 唯一索引创建（去重+加速）

适用场景：用户手机号、邮箱、订单号、身份证号等，这类字段需要保证唯一性，同时需要频繁查询，创建唯一索引既能实现去重，又能加速查询。

SQL示例（可直接复制）：

-- 用户表：给手机号创建唯一索引
CREATE UNIQUE INDEX idx_user_phone ON user(phone);

-- 用户表：给邮箱创建唯一索引
CREATE UNIQUE INDEX idx_user_email ON user(email);

-- 订单表：给订单号创建唯一索引
CREATE UNIQUE INDEX idx_order_no ON `order`(order_no);

注意事项：唯一索引允许为空，但空值只能有一个（MySQL中NULL != NULL，所以多个NULL值不会违反唯一约束）。如果字段需要非空+唯一，建议结合NOT NULL约束使用，比如"ALTER TABLE user MODIFY phone VARCHAR(20) NOT NULL;"，再创建唯一索引。

3.2.3 主键索引创建（表的核心索引）

适用场景：所有表都必须有主键索引，用于唯一标识每一行数据，同时加速主键查询（比如根据id查询详情）。优先使用自增主键（INT/BIGINT），避免使用UUID、字符串作为主键。

SQL示例（可直接复制）：

-- 方式1：创建表时直接指定主键索引（推荐）
CREATE TABLE user (
    id INT NOT NULL AUTO_INCREMENT COMMENT '自增主键',
    name VARCHAR(50) NOT NULL COMMENT '用户姓名',
    phone VARCHAR(20) NOT NULL COMMENT '手机号',
    PRIMARY KEY (id) -- 主键索引
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 方式2：给已存在的表添加主键索引
ALTER TABLE user ADD PRIMARY KEY (id);

注意事项：优先使用自增主键（INT/BIGINT），因为自增主键是有序的，创建索引时不会产生碎片，查询和写入效率都更高；避免使用UUID作为主键------UUID是无序的，每次插入数据时，MySQL需要重新排序索引，会产生大量索引碎片，降低查询和写入效率。

3.3 联合索引创建实战（高频进阶场景）

联合索引是实战中最常用的进阶索引类型，尤其是在多条件查询场景中，能大幅提升查询效率，但需要严格遵循"最左前缀原则"，否则会导致索引失效。

3.3.1 联合索引的设计逻辑（最左前缀原则详解）

联合索引的核心规则：最左前缀原则。比如创建联合索引（a,b,c），MySQL只能匹配以下三种查询条件，无法匹配其他条件：

1. 只查询a列（where a=xxx）；

2. 查询a+b列（where a=xxx and b=xxx）；

3. 查询a+b+c列（where a=xxx and b=xxx and c=xxx）。

而查询b列（where b=xxx）、c列（where c=xxx）、b+c列（where b=xxx and c=xxx），都无法匹配联合索引（a,b,c），会导致索引失效，触发全表扫描。这里需要特别注意一个误区：不满足最左前缀匹配原则≠索引完全失效，如果查询字段恰好是联合索引的一部分，可能会触发全索引扫描，虽然比全表扫描快，但仍需优化。

实战示例：订单表（order）有user_id、create_time、status三个字段，高频查询场景是"查询某用户某时间段的订单"（where user_id=xxx and create_time between '2026-01-01' and '2026-01-31'），此时创建联合索引（user_id, create_time），就能完美匹配该查询条件，大幅提升查询效率。

3.3.2 联合索引创建示例（可直接复制）

场景：订单表（order），高频查询"某用户的订单，按创建时间倒序排列"（where user_id=xxx order by create_time desc），需要创建联合索引，适配查询+排序场景。

SQL示例（可直接复制）：

-- 订单表：创建联合索引（user_id, create_time DESC）
CREATE INDEX idx_order_user_create ON `order`(user_id, create_time DESC);

优化点：排序字段（create_time）放在联合索引的末尾，并指定排序方向（DESC/ASC），这样MySQL可以直接通过索引获取排序后的结果，避免filesort，进一步提升查询效率。如果排序方向与索引方向不一致（比如索引是DESC，查询是ASC），仍会触发filesort，需要注意保持一致。

3.3.3 联合索引避坑：不要颠倒列的顺序

联合索引的列顺序非常关键，直接影响索引的匹配效果，很多人因为颠倒列顺序，导致索引失效，查询变慢。

反例：还是上面的订单表场景，高频查询是"查询某用户的订单"，如果创建联合索引（create_time, user_id），那么查询条件"where user_id=xxx"无法匹配该联合索引（不满足最左前缀原则），会触发全表扫描，索引相当于白建。

核心原则：区分度高的列、高频查询的列，放在联合索引的前面。比如订单表中，user_id的区分度比create_time高（一个用户可能有多个订单，user_id的唯一值更多），且user_id是高频查询条件，所以放在联合索引的前面；create_time作为排序字段，放在后面。

3.4 全文索引创建实战（文本搜索场景）

适用场景：文章表、商品描述表、新闻表等，需要进行模糊搜索（比如根据文章内容搜索、根据商品描述搜索），此时使用全文索引，比"like %xxx%"高效得多------"like %xxx%"会触发全表扫描，而全文索引能快速定位包含关键词的记录。

SQL示例（可直接复制）：

-- 文章表：给文章内容创建全文索引
CREATE FULLTEXT INDEX idx_article_content ON article(content);

-- 商品表：给商品描述创建全文索引
CREATE FULLTEXT INDEX idx_goods_desc ON goods(description);

使用方法：全文索引不能用like查询，需要用MATCH() AGAINST()函数，示例如下：

-- 搜索文章内容包含"MySQL索引"的文章
SELECT * FROM article WHERE MATCH(content) AGAINST('MySQL索引');

-- 搜索商品描述包含"性价比高"的商品
SELECT * FROM goods WHERE MATCH(description) AGAINST('性价比高');

注意事项：全文索引只支持CHAR、VARCHAR、TEXT类型的字段；如果需要搜索多个字段，可以创建多列全文索引（CREATE FULLTEXT INDEX idx_article_title_content ON article(title, content);）。

3.5 索引创建的工具与注意事项

除了用SQL命令创建索引，也可以使用可视化工具，适合新手操作；同时，创建索引时还有一些细节需要注意，避免影响业务运行。

1. 常用工具：Navicat、MySQL Workbench，这两个工具都支持可视化创建索引------右键点击表，选择"设计表"，找到"索引"选项，即可添加、修改、删除索引，操作简单，适合新手。

2. 注意事项：创建索引会锁表------InnoDB引擎默认是行锁（只有修改索引列的数据时才会锁行），MyISAM引擎是表锁（创建索引时会锁定整个表），所以尽量避免在业务高峰期创建索引，以免影响业务正常运行。建议在夜间低峰期创建索引，创建前做好数据备份。

3. 查看索引：创建索引后，可通过以下SQL查看索引是否创建成功、是否存在冗余：

-- 查看指定表的所有索引
SHOW INDEX FROM 表名;

-- 示例：查看user表的所有索引
SHOW INDEX FROM user;

四、进阶实战：索引优化技巧（解决"加了索引还是慢"的问题）

很多开发者都会遇到这样的问题：明明给字段创建了索引，但查询还是很慢，甚至和没加索引一样。这其实是索引失效了，或者索引设计不合理。本节我们重点讲解索引失效的高频场景、优化技巧，帮你解决"加了索引还是慢"的难题。

4.1 索引失效的10个高频场景（必看，避免踩坑）

索引失效是导致"加了索引还是慢"的核心原因，以下10个场景是实战中最常见的，一定要记牢，避免踩坑：

场景1：索引列使用函数。比如"SELECT * FROM user WHERE SUBSTR(name,1,3)='张'"，对name列（已创建索引）使用了SUBSTR函数，会导致索引失效，触发全表扫描。

场景2：索引列使用运算符。比如"SELECT * FROM user WHERE age+1=30""SELECT * FROM user WHERE phone!='13800138000'"，对索引列使用+、-、!、<>等运算符，可能导致索引失效（具体取决于数据分布，大概率会失效）。

场景3：索引列使用模糊查询（like %xxx）。比如"SELECT * FROM goods WHERE name LIKE '%手机'"，%在前面，会导致索引失效；而"SELECT * FROM goods WHERE name LIKE '手机%'"，%在后面，不会导致索引失效。

场景4：联合索引不遵循最左前缀原则。比如联合索引（a,b,c），查询条件是"where b=xxx and c=xxx"，不满足最左前缀原则，会导致索引失效（或触发全索引扫描）。

场景5：索引列存在NULL值。如果索引列允许为空，且查询条件中包含"where 列名 is null"，可能导致索引失效（MySQL对NULL值的处理特殊，尽量避免索引列允许为空）。

场景6：OR连接的条件中，有一列未创建索引。比如"SELECT * FROM user WHERE phone='13800138000' OR nickname='张三'"，如果phone列有索引，nickname列没有索引，会导致整个查询触发全表扫描，索引失效。

场景7：数据量过小（<10万）。此时MySQL优化器会认为全表扫描比索引扫描更快，会自动忽略索引，导致索引失效（这是正常现象，无需优化）。

场景8：索引列类型不匹配。比如phone列是VARCHAR类型（已创建索引），查询条件是"where phone=13800138000"（用数字查询字符串），会导致索引失效，触发全表扫描。

场景9：使用NOT IN、NOT EXISTS。比如"SELECT * FROM user WHERE id NOT IN (1,2,3)""SELECT * FROM user WHERE NOT EXISTS (SELECT 1 FROM order WHERE order.user_id=user.id)"，这类查询大概率会导致索引失效，触发全表扫描。

场景10：索引碎片过多。索引使用时间过长，频繁的插入、删除操作会导致索引碎片过多，索引查询效率下降，虽然不算"完全失效"，但会让查询变慢，误以为索引失效。

4.2 索引优化的8个实战技巧（直接套用，立竿见影）

针对上面的索引失效场景，我们给出8个实战优化技巧，直接套用就能解决"加了索引还是慢"的问题，立竿见影：

技巧1：避免索引列使用函数/运算符，重构SQL。比如将"SUBSTR(name,1,3)='张'"改为"name LIKE '张%'"；将"age+1=30"改为"age=29"；将"phone!='13800138000'"改为"phone<'13800138000' OR phone>'13800138000'"（如果数据分布合理，可能会走索引）。

技巧2：优化模糊查询，用like xxx%替代like %xxx%。如果必须使用"%xxx%"（比如搜索包含某个关键词的内容），建议使用全文索引，替代like查询，提升查询效率。

技巧3：联合索引遵循最左前缀原则，调整查询条件顺序。比如联合索引（a,b,c），查询条件"where b=xxx and a=xxx"，可以调整为"where a=xxx and b=xxx"，匹配联合索引；如果查询条件中没有a列，建议重新设计索引。

技巧4：索引列尽量非空，用默认值替代NULL。比如将name列的默认值设为""（空字符串），避免NULL值；如果字段确实需要允许为空，建议重新评估是否需要给该列创建索引。

技巧5：OR查询改为UNION查询，确保每个条件都有索引。比如"SELECT * FROM user WHERE phone='13800138000' OR nickname='张三'"，如果phone和nickname都有索引，可改为：

SELECT * FROM user WHERE phone='13800138000'
UNION
SELECT * FROM user WHERE nickname='张三';

这样两个子查询都会走索引，比OR查询高效得多。

技巧6：定期清理索引碎片，提升查询效率。对于频繁插入、删除的表，定期清理索引碎片，可使用以下SQL：

-- 清理索引碎片（InnoDB引擎）
OPTIMIZE TABLE 表名;

-- 示例：清理order表的索引碎片
OPTIMIZE TABLE `order`;

注意：OPTIMIZE TABLE会锁表，建议在低峰期执行，执行前做好数据备份。此外，也可以通过ALTER TABLE命令重建表，达到清理碎片的效果（ALTER TABLE 表名 ENGINE=InnoDB;）。

技巧7：删除冗余索引、无效索引，减少维护开销。定期查看表的索引（SHOW INDEX FROM 表名;），删除冗余索引（比如联合索引（a,b）对应的单独索引（a））、无效索引（长期不被使用的索引），减少写入操作的维护开销，同时提升查询效率。

技巧8：使用覆盖索引，避免回表查询。覆盖索引是一种进阶优化技巧，核心是"查询所需的列，全部包含在索引中"，MySQL无需回表查询主键对应的行数据，直接从索引中获取所有需要的字段，减少磁盘I/O，查询速度能提升50%以上。比如"SELECT id,name,phone FROM user WHERE id BETWEEN 100 AND 200"，如果创建联合索引（id,name,phone），就属于覆盖索引，无需回表。

4.3 覆盖索引实战（进阶优化，提升查询速度）

覆盖索引并非是一种独立的索引类型，而是一种基于联合索引的查询优化策略，实战中使用频率很高，能大幅提升查询速度，我们通过具体案例讲解：

核心逻辑：查询所需的所有列，都包含在索引中，MySQL无需回表（回表指的是通过索引找到主键后，再通过主键查询完整的行数据），直接从索引中获取数据，减少磁盘I/O操作。

实战场景：用户列表查询，需要展示用户的id、name、phone，查询条件是"where id BETWEEN 100 AND 200"，此时如果只给id列创建主键索引，MySQL会通过主键索引找到id对应的行，再回表查询name和phone，效率较低；如果创建联合索引（id,name,phone），查询所需的id、name、phone都包含在索引中，无需回表，直接从索引中获取数据，效率大幅提升。

SQL示例（可直接复制）：

-- 创建覆盖索引（包含查询所需的所有列）
CREATE INDEX idx_user_id_name_phone ON user(id, name, phone);

-- 执行查询（无需回表，直接从索引获取数据）
SELECT id,name,phone FROM user WHERE id BETWEEN 100 AND 200;

优势：减少磁盘I/O操作，查询速度提升50%以上；避免回表带来的性能开销，尤其适合高频查询场景。

注意事项：覆盖索引需要包含查询所需的所有列，不要包含无关列（否则会增加索引磁盘开销）；如果查询列较多，可适当取舍，优先保证高频查询的覆盖索引。

4.4 索引优化工具：用EXPLAIN分析索引使用情况（必学）

很多时候，我们不知道索引是否生效、查询是否走索引，这时候就需要用到EXPLAIN命令------EXPLAIN是MySQL自带的索引分析工具，能快速判断索引是否生效、查询是否需要优化，是每个开发者、DBA必学的工具。

核心命令：在查询SQL前添加EXPLAIN，即可分析查询的执行计划，示例如下：

-- 分析"查询手机号为13800138000的用户"的执行计划
EXPLAIN SELECT * FROM user WHERE phone='13800138000';

执行后，会返回一张执行计划表，我们重点关注3个字段，就能判断索引是否生效：

1. type：访问类型，核心指标，反映查询的效率，优先级从高到低为：const > ref > range > index > ALL。其中，const（通过主键或唯一索引直接定位单行，最优）、ref（使用非唯一索引或联合索引前缀匹配，高效）、range（索引范围扫描，如BETWEEN、>），这三种情况说明索引生效；index（全索引扫描，比全表快，但需优化）、ALL（全表扫描，需避免，除非数据量极小），这两种情况说明索引未生效或未被使用。

2. key：实际使用的索引，如果该字段为NULL，说明索引未生效，触发全表扫描；如果显示具体的索引名称（如idx_user_phone），说明索引生效，使用了该索引。

3. rows：MySQL预计扫描的行数，行数越少，查询效率越高；如果rows数值很大，说明查询需要扫描大量数据，需要优化索引或SQL。

实战分析示例：

假设user表的phone列创建了唯一索引idx_user_phone，执行"EXPLAIN SELECT * FROM user WHERE phone='13800138000'"，返回的type为const，key为idx_user_phone，rows为1，说明索引生效，查询效率极高；如果phone列没有创建索引，返回的type为ALL，key为NULL，rows为100000（假设表中有10万数据），说明索引未生效，触发全表扫描，需要创建索引优化。

补充说明：通过EXPLAIN还能发现其他问题，比如是否有filesort（排序优化）、是否有using temporary（临时表，需优化）等，后续排查查询慢问题时，会经常用到。

五、故障排查：查询慢与索引问题的快速解决（实战高频）

线上系统出现查询慢问题时，我们需要快速定位根源、解决问题，避免影响业务。本节我们讲解查询慢问题的排查流程，以及索引相关的高频故障解决方案，让你能快速搞定查询慢难题。

5.1 第一步：定位查询慢的根源（3个实用工具）

查询慢的原因有很多，可能是索引问题，也可能是SQL本身问题、服务器负载问题等，我们先通过3个实用工具，快速定位根源：

工具1：show processlist; ------ 查看当前运行的SQL，定位慢查询进程。执行该命令后，会显示当前MySQL正在执行的所有进程，重点关注"Time"字段（执行时间，单位：秒）和"Info"字段（具体的SQL语句），如果Time字段数值很大（比如超过5秒），且Info字段是具体的查询SQL，说明该SQL是慢查询，需要重点分析。

工具2：开启慢查询日志（slow_query_log）------ 记录执行时间超过阈值的SQL。默认情况下，慢查询日志是关闭的，我们可以通过以下SQL开启：

-- 开启慢查询日志
SET GLOBAL slow_query_log = ON;

-- 设置慢查询阈值（单位：秒，这里设为2秒，超过2秒的查询会被记录）
SET GLOBAL long_query_time = 2;

-- 查看慢查询日志存储路径
SHOW VARIABLES LIKE 'slow_query_log_file';

开启后，所有执行时间超过阈值的SQL都会被记录到慢查询日志中，我们可以查看日志，筛选出高频慢查询SQL，逐一优化。

工具3：EXPLAIN分析慢查询SQL ------ 判断是否索引失效、扫描行数过多。拿到慢查询SQL后，在前面添加EXPLAIN，分析执行计划，重点关注type、key、rows三个字段，判断是否是索引问题导致的查询慢。

5.2 高频故障场景：索引相关的查询慢解决方案（直接套用）

实战中，大部分查询慢问题都和索引相关，以下5个高频故障场景，给出具体的解决方案，直接套用就能解决：

场景1：全表扫描导致查询慢。症状：EXPLAIN分析显示type为ALL，key为NULL，rows数值很大；解决方案：创建合适的索引，根据查询条件，选择高频查询列、区分度高的列创建索引，创建后用EXPLAIN验证索引是否生效。

场景2：索引失效导致查询慢。症状：已创建索引，但EXPLAIN分析显示key为NULL，type为ALL；解决方案：对照4.1节的索引失效场景，检查SQL语句和索引设计，比如是否使用了函数、是否遵循联合索引最左前缀原则、是否存在类型不匹配等，修改SQL或索引，避免索引失效。

场景3：索引碎片过多导致查询慢。症状：索引已生效，但查询速度逐渐下降，表的插入、删除操作频繁；解决方案：在低峰期执行OPTIMIZE TABLE 表名，清理索引碎片，或用ALTER TABLE 表名 ENGINE=InnoDB;重建表，提升索引查询效率。

场景4：联合索引顺序不合理导致查询慢。症状：已创建联合索引，但查询仍触发全表扫描或全索引扫描；解决方案：调整联合索引列的顺序，将区分度高、高频查询的列放在前面，遵循最左前缀原则，重新创建联合索引。

场景5：大量重复数据导致索引效率低。症状：索引已生效，但查询速度仍很慢，表中存在大量重复数据；解决方案：删除重复数据，创建唯一索引或联合索引，保证数据唯一性，提升索引查询效率。

5.3 实战案例：从"查询慢"到"秒级响应"的完整优化流程

结合真实业务场景，完整还原查询慢问题的优化流程，让你学会如何在实际项目中排查、解决索引相关的查询慢问题：

案例背景：某电商系统的订单表（order），数据量100万条，表结构包含id（主键）、user_id、order_no、create_time、status、amount等字段，高频查询场景是"查询某用户30天内的订单"，执行SQL："SELECT * FROM order WHERE user_id=1001 AND create_time BETWEEN '2026-03-01' AND '2026-03-31'"，执行时间5秒+，严重影响接口响应速度。

优化步骤：

步骤1：用EXPLAIN分析慢查询SQL。执行"EXPLAIN SELECT * FROM order WHERE user_id=1001 AND create_time BETWEEN '2026-03-01' AND '2026-03-31'"，发现type为ALL，key为NULL，rows为1000000，说明索引未生效，触发全表扫描，这是查询慢的根源。

步骤2：排查索引失效原因。检查订单表的索引，发现只给id（主键索引）、order_no（唯一索引）创建了索引，user_id和create_time没有创建索引，也没有创建联合索引，所以查询时无法匹配索引，触发全表扫描。

步骤3：优化联合索引，调整列的顺序。根据查询条件"user_id=xxx AND create_time between xxx and xxx"，创建联合索引（user_id, create_time DESC）------user_id是高频查询列，区分度高，放在前面；create_time是范围查询列，放在后面，同时指定排序方向，适配查询场景。SQL示例：CREATE INDEX idx_order_user_create ON order(user_id, create_time DESC);

步骤4：优化SQL，使用覆盖索引。原SQL是"SELECT *"，会查询所有字段，需要回表；优化为"SELECT id,user_id,order_no,create_time,status,amount"（只查询需要的字段），并调整联合索引为（user_id, create_time DESC, order_no, status, amount），形成覆盖索引，避免回表。SQL示例：CREATE INDEX idx_order_user_create_cover ON order(user_id, create_time DESC, order_no, status, amount);

优化结果：查询时间从5秒+优化到50ms以内，实现秒级响应，接口QPS提升3倍以上，彻底解决查询慢问题。

六、实战案例：不同业务场景的索引设计与优化（企业级）

不同业务场景的索引设计的思路不同，本节结合3个企业级高频业务场景，讲解索引的设计与优化技巧，可直接套用在自己的项目中。

6.1 场景1：用户表索引设计（高频查询、去重）

表结构：id（主键）、phone（唯一）、name、age、create_time、gender，数据量50万条，高频查询场景：根据phone查询用户详情、根据name模糊查询用户列表、根据create_time查询某时间段注册的用户。

索引设计（可直接复制）：

-- 主键索引（必建）
ALTER TABLE user ADD PRIMARY KEY (id);

-- 唯一索引（phone去重+加速查询）
CREATE UNIQUE INDEX idx_user_phone ON user(phone);

-- 普通索引（name模糊查询，截取前缀）
CREATE INDEX idx_user_name ON user(name(20));

-- 联合索引（create_time+age，适配"查询某时间段注册的用户，按年龄筛选"）
CREATE INDEX idx_user_create_age ON user(create_time, age);

优化点：1. phone列需要唯一，创建唯一索引，同时加速phone查询；2. name列是长文本，截取前缀创建普通索引，减少磁盘开销；3. age列区分度低，不单独创建索引，结合create_time创建联合索引，适配多条件查询；4. 控制索引数量，共4个索引，未超过5个，避免写入开销过大。

6.2 场景2：订单表索引设计（高频查询、排序）

表结构：id（主键）、user_id、order_no（唯一）、create_time、status、amount、pay_time，数据量100万条，高频查询场景：根据user_id查询订单（按create_time倒序）、根据status查询订单（按create_time倒序）、根据order_no查询订单详情。

索引设计（可直接复制）：

-- 主键索引（必建）
ALTER TABLE `order` ADD PRIMARY KEY (id);

-- 唯一索引（order_no去重+加速查询）
CREATE UNIQUE INDEX idx_order_no ON `order`(order_no);

-- 联合索引（user_id+create_time DESC，适配"按用户查询订单，按时间倒序"）
CREATE INDEX idx_order_user_create ON `order`(user_id, create_time DESC);

-- 联合索引（status+create_time DESC，适配"按状态查询订单，按时间倒序"）
CREATE INDEX idx_order_status_create ON `order`(status, create_time DESC);

优化点：1. 排序字段（create_time）放在联合索引末尾，指定DESC方向，避免filesort；2. 两个高频查询场景（按用户、按状态），分别创建对应的联合索引，提升查询效率；3. order_no是唯一字段，创建唯一索引，同时加速详情查询；4. 索引数量4个，控制在合理范围。

6.3 场景3：商品表索引设计（模糊查询、筛选）

表结构：id（主键）、goods_name、category_id、price、sales、create_time、description，数据量200万条，高频查询场景：根据goods_name模糊查询、根据category_id筛选商品（按price排序）、根据sales查询热门商品、根据description模糊搜索商品。

索引设计（可直接复制）：

-- 主键索引（必建）
ALTER TABLE goods ADD PRIMARY KEY (id);

-- 普通索引（goods_name模糊查询，截取前缀）
CREATE INDEX idx_goods_name ON goods(goods_name(20));

-- 联合索引（category_id+price，适配"按分类筛选，按价格排序"）
CREATE INDEX idx_goods_category_price ON goods(category_id, price);

-- 普通索引（sales，适配"查询热门商品"）
CREATE INDEX idx_goods_sales ON goods(sales);

-- 全文索引（description，适配"模糊搜索商品描述"）
CREATE FULLTEXT INDEX idx_goods_desc ON goods(description);

优化点：1. goods_name是长文本，截取前缀创建普通索引，适配模糊查询（like xxx%）；2. category_id和price组合创建联合索引，适配"筛选+排序"场景，避免filesort；3. sales列是高频查询列，单独创建普通索引，加速热门商品查询；4. description列需要模糊搜索，创建全文索引，替代低效的like %xxx%查询；5. 索引数量5个，控制在合理范围。

七、避坑指南：MySQL索引实战10个高频坑（少走弯路）

结合实战经验，总结10个索引实战中的高频坑，每个坑都对应具体的避坑方法，帮你少走弯路，避免调试踩坑：

坑1：为所有列创建索引，导致写入操作（insert/update/delete）变慢。避坑方法：控制单表索引数量不超过5个，只给高频查询列、区分度高的列创建索引，避免冗余索引。

坑2：使用UUID作为主键，导致索引碎片过多，查询效率下降。避坑方法：优先使用自增主键（INT/BIGINT），如果必须使用UUID，可在插入时进行排序处理，减少索引碎片。

坑3：联合索引列顺序颠倒，导致索引失效，查询变慢。避坑方法：联合索引设计时，将区分度高、高频查询的列放在前面，遵循最左前缀原则，创建前先梳理高频查询场景。

坑4：索引列允许NULL，导致索引失效，全表扫描。避坑方法：索引列尽量非空，用默认值（如''、0）替代NULL，确实需要允许为空的字段，谨慎创建索引。

坑5：模糊查询用like %xxx，导致索引失效，查询效率极低。避坑方法：用like xxx%替代like %xxx%，必要时使用全文索引，适配文本模糊搜索场景。

坑6：忽略索引碎片，长期不清理，导致查询速度逐渐下降。避坑方法：对于频繁插入、删除的表，定期（如每月）在低峰期清理索引碎片，执行OPTIMIZE TABLE 表名。

坑7：小表创建索引，反而比全表扫描更慢。避坑方法：数据量<10万条的小表，无需创建索引，全表扫描效率更高；如果小表查询频繁，可根据实际情况创建1-2个核心索引。

坑8：索引列使用函数/运算符，导致索引失效。避坑方法：避免对索引列使用函数、运算符，重构SQL语句，将函数/运算符移到查询条件的右侧。

坑9：创建冗余索引，增加维护开销，无实际价值。避坑方法：定期查看表的索引，删除冗余索引（如联合索引（a,b）对应的单独索引（a））、无效索引，保持索引简洁。

坑10：过度依赖索引，忽略SQL本身的优化。避坑方法：索引是优化查询的手段，但不是唯一手段，还需要优化SQL语句（如避免子查询、优化join方式、减少不必要的字段查询），才能实现最优的查询效率。

八、总结：掌握这3点，彻底解决MySQL查询慢问题

MySQL索引实战的核心，不在于"建多少索引"，而在于"建对索引、用好索引、优化索引"，掌握以下3点，就能彻底解决MySQL查询慢问题，提升系统性能：

1. 创建索引：遵循"高频查询、区分度高、避免冗余"的原则，按业务场景选择合适的索引类型（普通索引、唯一索引、联合索引等），控制单表索引数量，不盲目建索引。

2. 优化索引：避开索引失效的10个高频场景，善用覆盖索引、联合索引，定期清理索引碎片，删除冗余索引、无效索引，确保索引始终高效。

3. 排查问题：熟练使用show processlist、慢查询日志、EXPLAIN三个工具，快速定位查询慢的根源，结合业务场景优化SQL和索引