索引下推（ICP）是MySQL 5.6+通过将部分WHERE条件（索引列上的过滤条件）下推至存储引擎层，在二级索引扫描时提前过滤，从而减少回表次数和I/O开销的优化机制；它默认开启，需满足二级索引、条件含索引非最左前缀列且支持引擎计算等触发条件，生效时EXPLAIN显示“Using index condition”。
索引下推（Index Condition Pushdown，ICP）是 MySQL 5.6+ 的原生优化能力，Java 应用无需特殊编码就能自动受益——关键在于数据库配置、SQL 写法和索引设计是否满足 ICP 触发条件。
确认 MySQL 已启用索引下推
ICP 默认开启，但需验证： ```sql SHOW VARIABLES LIKE 'optimizer_switch'; ``` 检查输出中是否包含 `index_condition_pushdown=on`。若为 `off`，可通过以下命令临时开启： ```sql SET optimizer_switch = 'index_condition_pushdown=on'; ``` 生产环境建议在 MySQL 配置文件（`my.cnf`）中持久化： ```ini [mysqld] optimizer_switch = "index_condition_pushdown=on" ```SQL 和索引必须匹配 ICP 触发条件
ICP 不是“用了索引就自动生效”，它只在特定组合下激活： - 必须使用**二级索引（非主键索引）**：聚簇索引（主键索引）本身含完整数据，无需回表，ICP 不起作用； - WHERE 条件中**至少有一个过滤列属于该二级索引，且不在最左前缀匹配范围内**： 例如联合索引 `(city, age)`，查询 `WHERE city = '杭州' AND age > 20` 可触发 ICP； 但 `WHERE city = '杭州'`（仅前缀等值）或 `WHERE age > 20`（跳过前缀）则无法利用该索引的 ICP（后者甚至可能不走索引）； - 过滤条件需支持**存储引擎层直接计算**：如 `=`, `>`, `通过 EXPLAIN 验证 ICP 是否生效 在 Java 开发中，执行 SQL 前用 `EXPLAIN` 检查执行计划： ```sql EXPLAIN SELECT name, age FROM user WHERE city = '杭州' AND age > 20; ``` 重点关注 `Extra` 列： - 出现 `Using index condition` → ICP 已启用，存储引擎在索引扫描时已过滤 `age > 20`； - 仅出现 `Using where` → 条件由 Server 层过滤，未下推，可能存在回表放大； - 出现 `Using index` → 覆盖索引，无需回表，ICP 不相关（此时性能已最优）。Java 侧配合建议
- 不要手动拼接 `/*+ USE_INDEX(...) */` 等 HINT 干预 ICP：MySQL 优化器会自主决策，强制索引可能反而禁用 ICP； - 使用 PreparedStatement 防止 SQL 注入，同时利于执行计划缓存，间接稳定 ICP 行为； - 在 MyBatis 中，避免在 `ICP 是透明的底层加速机制，Java 层真正要做的，是让 SQL 和索引“配得上”它——写对条件、建对索引、看懂执行计划。
