ICP能减少回表次数，因其将Server层的部分WHERE过滤下推至存储引擎层，在二级索引扫描时直接判断索引中已包含的条件列（如联合索引中的非前缀列），不满足即跳过，避免无效回表。
ICP 为什么能减少回表次数
因为 ICP 把原本在 Server 层做的部分 WHERE 过滤，提前挪到了存储引擎扫描索引时同步执行——只要该条件涉及的列，恰好包含在当前使用的二级索引中，InnoDB 就能在遍历索引节点的过程中直接判断真假，不满足就跳过，根本不会触发后续的回表动作。
关键前提：条件必须能被索引“覆盖”
ICP 不是万能的，它只对满足以下条件的 WHERE 子句生效：
-
WHERE中有至少一个非索引前缀列（比如联合索引(name, age)，但查询写了name LIKE '张%' AND age = 10，其中age是第二列，可下推） - 该列实际存在于所用的二级索引叶子节点里（即索引“包含”这个字段，不是靠回表才能拿到）
- 查询类型是
SELECT（UPDATE/DELETE不支持 ICP） - 使用的是 InnoDB 的二级索引（聚簇索引本身不回表，ICP 对其无意义）
对比没有 ICP 时的流程差异
以 SELECT * FROM tuser WHERE name LIKE '张%' AND age = 10 和联合索引 name_age(name, age) 为例：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 无 ICP：InnoDB 扫描所有
name LIKE '张%'的索引项 → 拿到全部匹配的主键（比如 5 条）→ 全部回表查聚簇索引 → Server 层再逐行检查age = 10→ 最终可能只剩 1 行有效 - 有 ICP：InnoDB 扫描索引时，每读一个
(name, age)索引条目，就当场判断age = 10→ 只对满足的条目才用主键去回表 → 回表次数从 5 次降到 1 次
区别不在“多扫了还是少扫了索引”，而在于“扫完索引后要不要全量回表”。ICP 把过滤动作前置到了索引遍历环节，天然规避无效回表。
如何确认 ICP 是否真的启用
看 EXPLAIN 输出的 Extra 列：
- 出现
Using index condition→ ICP 已生效 - 只有
Using where→ 条件仍在 Server 层过滤，ICP 未触发（常见于条件列不在索引中、或用了不支持下推的函数如UPPER(name)） - 注意：
Using index表示覆盖索引，和 ICP 无关，别混淆
真正容易被忽略的是：ICP 的收益高度依赖索引设计。如果联合索引顺序写反（比如建了 (age, name) 却查 name LIKE '张%' AND age = 10），最左匹配失败，连索引都用不上，更谈不上 ICP。所以不是开了 MySQL 5.6+ 就自动优化，得让条件和索引结构对得上才行。
