在实际 MySQL 性能优化和面试场景中索引下推是一个高频出现且容易混淆的概念。很多开发者知道索引能加速查询但面对“索引下推”这个名词时往往只能说出“减少回表”这个模糊的印象却说不清它具体在哪个环节生效、解决了什么问题、以及如何验证其效果。这导致在排查慢查询或进行深度优化时无法精准利用这一特性。本文将深入解析 MySQL 索引下推的工作原理从存储引擎层的数据处理逻辑入手通过对比开启与关闭索引下推的执行计划差异并结合具体 SQL 示例让你不仅能在面试中清晰阐述更能将其应用于实际的数据库性能调优中。1. 理解索引下推要解决的性能瓶颈要理解索引下推必须先明确一个没有它时存在的性能瓶颈在复合索引查询中非索引列条件的过滤时机过晚。1.1 一个典型的低效查询场景假设有一张用户表user并建立了一个复合索引idx_age_city(age,city)。CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(50) DEFAULT NULL, age int(11) DEFAULT NULL, city varchar(50) DEFAULT NULL, status tinyint(4) DEFAULT NULL, PRIMARY KEY (id), KEY idx_age_city (age,city) ) ENGINEInnoDB;现在执行这样一条查询SELECT * FROM user WHERE age 20 AND city 杭州 AND status 1;在这个查询中WHERE条件包含三部分age 20匹配索引idx_age_city的第一列范围查询。city 杭州匹配索引idx_age_city的第二列。status 1条件中的status列没有包含在索引中。1.2 没有索引下推时MySQL 5.6之前的处理流程在 MySQL 5.6 引入索引下推之前对于上述查询即使使用了复合索引处理流程也是低效的存储引擎层根据索引idx_age_city定位所有满足age 20条件的记录。注意此时只使用了索引的第一列进行定位因为age是范围查询其后的索引列city在索引结构里无法再以等值方式快速定位。存储引擎会将这些满足age 20的记录的主键 ID返回给 Server 层。Server 层拿到这些主键 ID 后回到存储引擎通过主键索引聚簇索引进行回表操作取出完整的行数据。Server 层在 Server 层的内存中对取出的每一行完整数据应用剩下的WHERE条件进行过滤即判断city 杭州 AND status 1是否成立。这个流程的核心问题在于city列本身是索引idx_age_city的一部分但它的等值过滤条件 (city 杭州) 并没有在存储引擎层利用索引进行过滤而是被推迟到 Server 层在回表之后才进行。这导致了大量不必要的回表操作。例如存储引擎可能找到了 10000 条age 20的记录但其中可能只有 100 条city 杭州。在没有索引下推的情况下这 10000 条记录都需要回表然后 Server 层再丢弃其中 9900 条city不匹配的记录造成了巨大的 I/O 和 CPU 浪费。2. 索引下推的工作原理与生效条件索引下推的英文是 Index Condition Pushdown简称 ICP。它的设计目标就是将上述低效流程中的部分过滤操作从 Server 层“下推”到存储引擎层去执行。2.1 开启索引下推后的处理流程同样对于查询SELECT * FROM user WHERE age 20 AND city 杭州 AND status 1;在启用 ICP 后存储引擎层根据索引idx_age_city定位所有满足age 20条件的记录。存储引擎层在存储引擎内部直接利用索引中已有的city列信息对第一步找到的记录进行city 杭州的过滤。注意status列不在索引中所以此时无法对status 1进行过滤。存储引擎层将满足age 20 AND city 杭州的记录的主键 ID返回给 Server 层。此时返回的记录数大大减少从 10000 条减至约 100 条。Server 层拿到主键 ID 进行回表取出完整的行数据。Server 层在内存中对取出的行数据应用剩余的WHERE条件status 1进行过滤。对比可知ICP 的核心价值在于将索引中包含的列的过滤条件在存储引擎层进行提前过滤从而减少不必要的回表次数和 Server 层与存储引擎层之间的数据传输量。2.2 索引下推的生效条件不是所有查询都能受益于 ICP。它的生效有严格的前提表必须是 InnoDB 或 MyISAM 引擎。这是 MySQL 官方支持 ICP 的引擎。查询需要用到二级索引非聚簇索引。因为聚簇索引主键索引本身包含了全部数据不存在“下推过滤后再回表”的场景。WHERE 条件中有部分条件涉及到的列被包含在使用的复合索引中但这些条件无法直接作为索引的访问条件Access Method来使用。最常见的情况就是范围查询后面的索引列条件。访问条件像age 20或age 20这种能直接用于在索引树中定位扫描起点和终点的条件。下推条件像city 杭州这种在age 20这个范围查询之后它无法再用于索引定位但可以利用索引中存储的city列值在引擎层进行过滤。ICP 默认是开启的。可以通过系统变量optimizer_switch来控制SET optimizer_switch index_condition_pushdownoff;用于关闭SET optimizer_switch index_condition_pushdownon;用于开启。注意即使status 1这个条件也写在 WHERE 子句中但它不会被下推因为status列不在idx_age_city索引中。存储引擎层根本没有status的数据自然无法过滤。3. 通过执行计划验证索引下推最直观验证 ICP 是否生效的方式是查看 SQL 的执行计划。使用EXPLAIN命令关注Extra列。3.1 创建测试数据与查询我们先准备一些测试数据并执行一个典型查询。-- 插入测试数据假设数据分布符合我们的场景 INSERT INTO user (name, age, city, status) VALUES (张三, 25, 北京, 1), (李四, 18, 杭州, 0), (王五, 30, 杭州, 1), (赵六, 22, 上海, 1), (孙七, 28, 杭州, 0); -- ... 可以多插入一些数据以方便观察 -- 分析查询语句 EXPLAIN SELECT * FROM user WHERE age 20 AND city 杭州 AND status 1;3.2 解读 EXPLAIN 输出执行EXPLAIN后你会看到类似下面的输出具体值可能不同idselect_typetablepartitionstypepossible_keyskeykey_lenrefrowsfilteredExtra1SIMPLEuserNULLrangeidx_age_cityidx_age_city5NULL333.33Using index condition; Using where这里需要重点关注Extra列Using index condition这是索引下推ICP生效的标志它表示存储引擎层将 WHERE 条件中属于索引的列本例中的city进行了过滤。Using where表示在 Server 层对存储引擎返回的行应用了剩余的、无法在引擎层完成的过滤条件本例中的status 1。如果关闭 ICP再查看执行计划SET optimizer_switch index_condition_pushdownoff; EXPLAIN SELECT * FROM user WHERE age 20 AND city 杭州 AND status 1; SET optimizer_switch index_condition_pushdownon; -- 记得重新打开关闭 ICP 后Extra列可能只显示Using where表示所有过滤都发生在 Server 层存储引擎只是简单地根据age 20返回所有主键。3.3 关键指标对比通过EXPLAIN的rows和filtered字段也能侧面反映 ICP 的效果需注意这些是估算值rows表示存储引擎根据访问方法age 20预计要检查的行数。filtered表示在存储引擎层过滤后预计剩余行数所占的百分比。在 ICP 生效时这个值可能更准确地反映经过city过滤后的结果比例。但更可靠的判断还是看Extra列。4. 索引下推的典型应用场景与边界理解 ICP 的应用场景和不能生效的场景有助于在设计和优化查询时做出正确决策。4.1 最能发挥效能的场景复合索引 范围查询 后续索引列等值查询如前文所述这是最经典的场景。WHERE a 1 AND b 2索引是(a, b)。复合索引 LIKE 前缀匹配WHERE a 1 AND b LIKE abc%索引是(a, b)。b LIKE abc%在索引中可以被下推过滤。覆盖索引查询如果查询只需要索引列即使没有 ICP性能也很好。但 ICP 在覆盖索引的场景下依然工作只是收益不如需要回表的场景那么显著因为本身就不需要回表。4.2 索引下推无法生效的场景条件引用的列不在索引中这是最根本的限制。WHERE a 1 AND c 2索引是(a, b)条件c 2无法下推。索引访问方式是index全索引扫描或ALL全表扫描ICP 适用于ref,range,eq_ref,const等通过索引定位数据的访问方式。如果优化器决定扫描整个索引或整个表下推的意义不大。子查询或连接查询中的某些复杂情况ICP 最初主要针对单表查询优化在复杂连接中的支持可能有限具体取决于 MySQL 版本和优化器选择。使用了函数或表达式WHERE a 1 AND UPPER(b) VALUE即使b在索引中因为使用了函数UPPER()这个条件通常也无法下推。访问方法是const或system这类查询最多返回一行优化空间极小ICP 无关紧要。4.3 索引设计启示ICP 特性影响了我们设计复合索引时的思考维度将等值查询的列放在范围查询的列之前这依然是最高优先级的原则最左前缀原则。在满足最左前缀的前提下如果查询中经常出现WHERE a ? AND b ?那么建立(a, b)索引并利用 ICP比只建立(a)索引性能要好得多。因为(a)索引无法在引擎层过滤b。然而这并不意味着可以随意设计索引。如果查询是WHERE a ? AND b ?那么索引(a, b)中的b可以直接作为范围查询的访问条件其效率通常高于(b, a)加 ICP 的方式。因为作为访问条件直接定位比下推过滤更高效。5. 生产环境中的排查与最佳实践了解原理后如何在真实系统中应用和排查 ICP 相关的问题5.1 如何确认查询是否从 ICP 受益查看执行计划使用EXPLAIN查看Extra列是否有Using index condition。这是金标准。对比性能在测试环境通过SET optimizer_switch临时关闭 ICP运行相同查询对比执行时间或慢查询日志中的耗时。注意确保缓存Query Cache, Buffer Pool已被清除以获得公平对比。观察状态变量MySQL 提供了Handler_%状态变量来粗略观察存储引擎层的活动。ICP 可以减少Handler_read_rnd_next随机读下一行的次数因为回表次数减少了。但这不是精确指标。5.2 常见问题排查清单当怀疑 ICP 未按预期工作时可以按以下清单排查问题现象可能原因检查方式处理建议EXPLAIN未显示Using index condition1. ICP 被全局或会话级关闭。2. 查询条件中的列不在使用的索引中。3. 访问方法不是ref或range等。1. 执行SELECT optimizer_switch;查看index_condition_pushdown是否on。2. 检查EXPLAIN的key列确认使用的索引对比WHERE条件。3. 检查EXPLAIN的type列。1. 开启 ICP。2. 考虑调整索引设计将过滤条件列加入索引。3. 尝试优化查询使其能使用更高效的索引访问方式。查询性能提升不明显1. 下推过滤掉的数据比例不高选择性低。2. 查询本身需要处理的数据量很小。3. 回表成本因其他原因如缓冲池命中率依然很高。1. 分析WHERE条件的选择性。city杭州如果匹配大部分数据下推收益小。2. 使用EXPLAIN ANALYZEMySQL 8.0查看实际执行成本分布。1. ICP 是“锦上添花”优化索引本身选择性和访问方式是根本。2. 对于小数据量查询优化收益本就有限。不同版本行为不一致ICP 在 MySQL 5.6 引入后续版本有持续优化和增强。查阅对应版本的官方手册 Release Notes。确认生产环境 MySQL 版本并在相同版本测试环境验证。5.3 最佳实践与注意事项保持默认开启除非有极特殊的兼容性原因否则应将optimizer_switch中的index_condition_pushdown保持为on。它是重要的性能优化器。理解其辅助定位ICP 是“索引访问”的辅助优化手段不能替代良好的索引设计。首要任务永远是设计出能够被直接用作访问条件ref,range的高效索引。关注版本差异MySQL 5.6 引入了基本 ICP 支持5.7 和 8.0 版本对其进行了增强例如对分区表、虚拟列索引的支持更好。在迁移或升级时应对关键查询进行性能回归测试。结合覆盖索引如果查询能通过覆盖索引完成EXPLAIN的Extra列出现Using index则无需回表ICP 的收益主要体现在减少 Server 层与引擎层的数据传输上。此时Using index condition和Using index可能同时出现。不要过度解读Using index condition是一个积极的信号但它不直接等同于“性能最优”。仍需结合type,rows,key_len等字段综合判断整个执行计划的效率。索引下推是 MySQL 优化器将计算任务尽可能下推到数据存储层的一个典型例子其思想与很多现代数据库和计算引擎如向量化执行相通。掌握它不仅能让你在面试中游刃有余更能让你在分析EXPLAIN执行计划、设计高效索引和编写优质 SQL 时多一个有力的理论工具和观察视角。下次面对慢查询不妨先看看Extra列思考一下是否可以通过调整索引或查询条件让 ICP 这位“幕后功臣”发挥更大的作用。
在实际 MySQL 性能优化和面试场景中索引下推是一个高频出现且容易混淆的概念。很多开发者知道索引能加速查询但面对“索引下推”这个名词时往往只能说出“减少回表”这个模糊的印象却说不清它具体在哪个环节生效、解决了什么问题、以及如何验证其效果。这导致在排查慢查询或进行深度优化时无法精准利用这一特性。本文将深入解析 MySQL 索引下推的工作原理从存储引擎层的数据处理逻辑入手通过对比开启与关闭索引下推的执行计划差异并结合具体 SQL 示例让你不仅能在面试中清晰阐述更能将其应用于实际的数据库性能调优中。1. 理解索引下推要解决的性能瓶颈要理解索引下推必须先明确一个没有它时存在的性能瓶颈在复合索引查询中非索引列条件的过滤时机过晚。1.1 一个典型的低效查询场景假设有一张用户表user并建立了一个复合索引idx_age_city(age,city)。CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(50) DEFAULT NULL, age int(11) DEFAULT NULL, city varchar(50) DEFAULT NULL, status tinyint(4) DEFAULT NULL, PRIMARY KEY (id), KEY idx_age_city (age,city) ) ENGINEInnoDB;现在执行这样一条查询SELECT * FROM user WHERE age 20 AND city 杭州 AND status 1;在这个查询中WHERE条件包含三部分age 20匹配索引idx_age_city的第一列范围查询。city 杭州匹配索引idx_age_city的第二列。status 1条件中的status列没有包含在索引中。1.2 没有索引下推时MySQL 5.6之前的处理流程在 MySQL 5.6 引入索引下推之前对于上述查询即使使用了复合索引处理流程也是低效的存储引擎层根据索引idx_age_city定位所有满足age 20条件的记录。注意此时只使用了索引的第一列进行定位因为age是范围查询其后的索引列city在索引结构里无法再以等值方式快速定位。存储引擎会将这些满足age 20的记录的主键 ID返回给 Server 层。Server 层拿到这些主键 ID 后回到存储引擎通过主键索引聚簇索引进行回表操作取出完整的行数据。Server 层在 Server 层的内存中对取出的每一行完整数据应用剩下的WHERE条件进行过滤即判断city 杭州 AND status 1是否成立。这个流程的核心问题在于city列本身是索引idx_age_city的一部分但它的等值过滤条件 (city 杭州) 并没有在存储引擎层利用索引进行过滤而是被推迟到 Server 层在回表之后才进行。这导致了大量不必要的回表操作。例如存储引擎可能找到了 10000 条age 20的记录但其中可能只有 100 条city 杭州。在没有索引下推的情况下这 10000 条记录都需要回表然后 Server 层再丢弃其中 9900 条city不匹配的记录造成了巨大的 I/O 和 CPU 浪费。2. 索引下推的工作原理与生效条件索引下推的英文是 Index Condition Pushdown简称 ICP。它的设计目标就是将上述低效流程中的部分过滤操作从 Server 层“下推”到存储引擎层去执行。2.1 开启索引下推后的处理流程同样对于查询SELECT * FROM user WHERE age 20 AND city 杭州 AND status 1;在启用 ICP 后存储引擎层根据索引idx_age_city定位所有满足age 20条件的记录。存储引擎层在存储引擎内部直接利用索引中已有的city列信息对第一步找到的记录进行city 杭州的过滤。注意status列不在索引中所以此时无法对status 1进行过滤。存储引擎层将满足age 20 AND city 杭州的记录的主键 ID返回给 Server 层。此时返回的记录数大大减少从 10000 条减至约 100 条。Server 层拿到主键 ID 进行回表取出完整的行数据。Server 层在内存中对取出的行数据应用剩余的WHERE条件status 1进行过滤。对比可知ICP 的核心价值在于将索引中包含的列的过滤条件在存储引擎层进行提前过滤从而减少不必要的回表次数和 Server 层与存储引擎层之间的数据传输量。2.2 索引下推的生效条件不是所有查询都能受益于 ICP。它的生效有严格的前提表必须是 InnoDB 或 MyISAM 引擎。这是 MySQL 官方支持 ICP 的引擎。查询需要用到二级索引非聚簇索引。因为聚簇索引主键索引本身包含了全部数据不存在“下推过滤后再回表”的场景。WHERE 条件中有部分条件涉及到的列被包含在使用的复合索引中但这些条件无法直接作为索引的访问条件Access Method来使用。最常见的情况就是范围查询后面的索引列条件。访问条件像age 20或age 20这种能直接用于在索引树中定位扫描起点和终点的条件。下推条件像city 杭州这种在age 20这个范围查询之后它无法再用于索引定位但可以利用索引中存储的city列值在引擎层进行过滤。ICP 默认是开启的。可以通过系统变量optimizer_switch来控制SET optimizer_switch index_condition_pushdownoff;用于关闭SET optimizer_switch index_condition_pushdownon;用于开启。注意即使status 1这个条件也写在 WHERE 子句中但它不会被下推因为status列不在idx_age_city索引中。存储引擎层根本没有status的数据自然无法过滤。3. 通过执行计划验证索引下推最直观验证 ICP 是否生效的方式是查看 SQL 的执行计划。使用EXPLAIN命令关注Extra列。3.1 创建测试数据与查询我们先准备一些测试数据并执行一个典型查询。-- 插入测试数据假设数据分布符合我们的场景 INSERT INTO user (name, age, city, status) VALUES (张三, 25, 北京, 1), (李四, 18, 杭州, 0), (王五, 30, 杭州, 1), (赵六, 22, 上海, 1), (孙七, 28, 杭州, 0); -- ... 可以多插入一些数据以方便观察 -- 分析查询语句 EXPLAIN SELECT * FROM user WHERE age 20 AND city 杭州 AND status 1;3.2 解读 EXPLAIN 输出执行EXPLAIN后你会看到类似下面的输出具体值可能不同idselect_typetablepartitionstypepossible_keyskeykey_lenrefrowsfilteredExtra1SIMPLEuserNULLrangeidx_age_cityidx_age_city5NULL333.33Using index condition; Using where这里需要重点关注Extra列Using index condition这是索引下推ICP生效的标志它表示存储引擎层将 WHERE 条件中属于索引的列本例中的city进行了过滤。Using where表示在 Server 层对存储引擎返回的行应用了剩余的、无法在引擎层完成的过滤条件本例中的status 1。如果关闭 ICP再查看执行计划SET optimizer_switch index_condition_pushdownoff; EXPLAIN SELECT * FROM user WHERE age 20 AND city 杭州 AND status 1; SET optimizer_switch index_condition_pushdownon; -- 记得重新打开关闭 ICP 后Extra列可能只显示Using where表示所有过滤都发生在 Server 层存储引擎只是简单地根据age 20返回所有主键。3.3 关键指标对比通过EXPLAIN的rows和filtered字段也能侧面反映 ICP 的效果需注意这些是估算值rows表示存储引擎根据访问方法age 20预计要检查的行数。filtered表示在存储引擎层过滤后预计剩余行数所占的百分比。在 ICP 生效时这个值可能更准确地反映经过city过滤后的结果比例。但更可靠的判断还是看Extra列。4. 索引下推的典型应用场景与边界理解 ICP 的应用场景和不能生效的场景有助于在设计和优化查询时做出正确决策。4.1 最能发挥效能的场景复合索引 范围查询 后续索引列等值查询如前文所述这是最经典的场景。WHERE a 1 AND b 2索引是(a, b)。复合索引 LIKE 前缀匹配WHERE a 1 AND b LIKE abc%索引是(a, b)。b LIKE abc%在索引中可以被下推过滤。覆盖索引查询如果查询只需要索引列即使没有 ICP性能也很好。但 ICP 在覆盖索引的场景下依然工作只是收益不如需要回表的场景那么显著因为本身就不需要回表。4.2 索引下推无法生效的场景条件引用的列不在索引中这是最根本的限制。WHERE a 1 AND c 2索引是(a, b)条件c 2无法下推。索引访问方式是index全索引扫描或ALL全表扫描ICP 适用于ref,range,eq_ref,const等通过索引定位数据的访问方式。如果优化器决定扫描整个索引或整个表下推的意义不大。子查询或连接查询中的某些复杂情况ICP 最初主要针对单表查询优化在复杂连接中的支持可能有限具体取决于 MySQL 版本和优化器选择。使用了函数或表达式WHERE a 1 AND UPPER(b) VALUE即使b在索引中因为使用了函数UPPER()这个条件通常也无法下推。访问方法是const或system这类查询最多返回一行优化空间极小ICP 无关紧要。4.3 索引设计启示ICP 特性影响了我们设计复合索引时的思考维度将等值查询的列放在范围查询的列之前这依然是最高优先级的原则最左前缀原则。在满足最左前缀的前提下如果查询中经常出现WHERE a ? AND b ?那么建立(a, b)索引并利用 ICP比只建立(a)索引性能要好得多。因为(a)索引无法在引擎层过滤b。然而这并不意味着可以随意设计索引。如果查询是WHERE a ? AND b ?那么索引(a, b)中的b可以直接作为范围查询的访问条件其效率通常高于(b, a)加 ICP 的方式。因为作为访问条件直接定位比下推过滤更高效。5. 生产环境中的排查与最佳实践了解原理后如何在真实系统中应用和排查 ICP 相关的问题5.1 如何确认查询是否从 ICP 受益查看执行计划使用EXPLAIN查看Extra列是否有Using index condition。这是金标准。对比性能在测试环境通过SET optimizer_switch临时关闭 ICP运行相同查询对比执行时间或慢查询日志中的耗时。注意确保缓存Query Cache, Buffer Pool已被清除以获得公平对比。观察状态变量MySQL 提供了Handler_%状态变量来粗略观察存储引擎层的活动。ICP 可以减少Handler_read_rnd_next随机读下一行的次数因为回表次数减少了。但这不是精确指标。5.2 常见问题排查清单当怀疑 ICP 未按预期工作时可以按以下清单排查问题现象可能原因检查方式处理建议EXPLAIN未显示Using index condition1. ICP 被全局或会话级关闭。2. 查询条件中的列不在使用的索引中。3. 访问方法不是ref或range等。1. 执行SELECT optimizer_switch;查看index_condition_pushdown是否on。2. 检查EXPLAIN的key列确认使用的索引对比WHERE条件。3. 检查EXPLAIN的type列。1. 开启 ICP。2. 考虑调整索引设计将过滤条件列加入索引。3. 尝试优化查询使其能使用更高效的索引访问方式。查询性能提升不明显1. 下推过滤掉的数据比例不高选择性低。2. 查询本身需要处理的数据量很小。3. 回表成本因其他原因如缓冲池命中率依然很高。1. 分析WHERE条件的选择性。city杭州如果匹配大部分数据下推收益小。2. 使用EXPLAIN ANALYZEMySQL 8.0查看实际执行成本分布。1. ICP 是“锦上添花”优化索引本身选择性和访问方式是根本。2. 对于小数据量查询优化收益本就有限。不同版本行为不一致ICP 在 MySQL 5.6 引入后续版本有持续优化和增强。查阅对应版本的官方手册 Release Notes。确认生产环境 MySQL 版本并在相同版本测试环境验证。5.3 最佳实践与注意事项保持默认开启除非有极特殊的兼容性原因否则应将optimizer_switch中的index_condition_pushdown保持为on。它是重要的性能优化器。理解其辅助定位ICP 是“索引访问”的辅助优化手段不能替代良好的索引设计。首要任务永远是设计出能够被直接用作访问条件ref,range的高效索引。关注版本差异MySQL 5.6 引入了基本 ICP 支持5.7 和 8.0 版本对其进行了增强例如对分区表、虚拟列索引的支持更好。在迁移或升级时应对关键查询进行性能回归测试。结合覆盖索引如果查询能通过覆盖索引完成EXPLAIN的Extra列出现Using index则无需回表ICP 的收益主要体现在减少 Server 层与引擎层的数据传输上。此时Using index condition和Using index可能同时出现。不要过度解读Using index condition是一个积极的信号但它不直接等同于“性能最优”。仍需结合type,rows,key_len等字段综合判断整个执行计划的效率。索引下推是 MySQL 优化器将计算任务尽可能下推到数据存储层的一个典型例子其思想与很多现代数据库和计算引擎如向量化执行相通。掌握它不仅能让你在面试中游刃有余更能让你在分析EXPLAIN执行计划、设计高效索引和编写优质 SQL 时多一个有力的理论工具和观察视角。下次面对慢查询不妨先看看Extra列思考一下是否可以通过调整索引或查询条件让 ICP 这位“幕后功臣”发挥更大的作用。
