是，extra字段显示using index condition即表示启用了索引下推（icp）；该标志是判断icp是否生效的唯一可靠依据，需结合innodb引擎、mysql≥5.6、联合索引中可下推谓词等条件综合确认。
explain 中的 extra 字段是否含 using index condition
navicat 本身不直接标注“索引下推”（icp），但你能通过它执行 explain 后观察 extra 字段来判断是否发生。只要看到 using index condition，就说明 mysql 启用了索引下推——这是唯一可靠信号。
注意：Using index ≠ 索引下推，那是覆盖索引；Using where 也不代表 ICP，它只表示 Server 层做了过滤。
- 必须用 InnoDB 引擎（MyISAM 不支持 ICP）
- 查询条件中需有**可下推到存储引擎的谓词**，比如
WHERE status = 'active' AND name LIKE 'a%'，其中name LIKE 'a%'若在联合索引后缀字段上，才可能下推 - MySQL 版本需 ≥ 5.6（ICP 默认开启，无需额外配置）
联合索引中范围查询字段位置影响 ICP 是否生效
索引下推能否触发，关键看范围条件（>、、<code>BETWEEN、LIKE 前缀匹配）是否出现在联合索引的**非最左连续部分**。
例如联合索引 idx_status_name_age（status, name, age）：
-
WHERE status = 'active' AND name > 'li'→name > 'li'是范围，但它在第二位，仍可下推，EXPLAIN显示Using index condition -
WHERE name > 'li'（跳过 status）→ 索引无法从左开始匹配，走不了该联合索引，自然无 ICP -
WHERE status = 'active' AND age > 25→age是第三列且为范围，但前两列未全等值（name缺失），age条件无法下推，Extra里只有Using where
Navicat 执行 EXPLAIN 的实操要点
在 Navicat 查询窗口中运行 EXPLAIN 时，容易忽略几个细节，导致误判：
- 别用
EXPLAIN FORMAT=JSON—— Navicat 对 JSON 格式展示不友好，字段易被截断，坚持用默认表格格式 - 确保没开查询缓存（
SELECT @@query_cache_type应为 0），否则EXPLAIN可能返回缓存路径而非真实执行计划 - 如果语句含子查询或 UNION，
EXPLAIN输出会有多行，要逐行检查每张表的Extra，ICP 只作用于单表扫描阶段 - 执行前先用
ANALYZE TABLE users;更新统计信息，避免优化器因过期行数估算而放弃 ICP
对比测试：加 FORCE INDEX 后 Extra 变化是否合理
当你怀疑优化器没选对索引、想验证 ICP 是否被启用时，可用 FORCE INDEX 强制走某个联合索引，再比对 EXPLAIN 输出：
- 原语句：
EXPLAIN SELECT * FROM users WHERE status = 'active' AND name LIKE 'z%';→Extra: Using where - 强制索引：
EXPLAIN SELECT * FROM users FORCE INDEX (idx_status_name) WHERE status = 'active' AND name LIKE 'z%';→ 若此时出现Using index condition，说明该索引结构支持 ICP，但优化器之前因成本估算放弃了它 - 注意：强制索引后
rows数变小 +Extra出现Using index condition，才是 ICP 生效的双重证据
真正容易被忽略的是：ICP 是否生效，不取决于你写了什么条件，而取决于**索引定义顺序**和**优化器对数据分布的估算**——哪怕条件完全一样，10万行和1000行的表，EXPLAIN 结果都可能不同。
