答案是Index Condition Pushdown（ICP）机制：MySQL将部分WHERE条件（仅限索引列）下推至存储引擎层，在二级索引扫描时提前过滤，减少回表次数；执行计划中显示“Using index condition”即表示启用ICP，但不改变索引使用判断。
为什么 WHERE 条件没走索引，却说“用了索引”？
因为 MySQL 在二级索引扫描时，把部分 WHERE 条件下推到存储引擎层执行，而不是等回表后再过滤。这叫 Index Condition Pushdown（ICP）。它不改变“是否使用索引”的判断，但显著减少回表次数和无效数据传输。
典型现象：执行计划里 Extra 字段出现 Using index condition，但 type 是 ref 或 range，且实际扫描行数远小于回表行数。
- ICP 只在
WHERE中包含索引列的条件才生效，比如联合索引(a, b, c)，WHERE a = 1 AND b > 2 AND c = 3中b > 2和c = 3都可能被下推 - 不能下推的条件包括：涉及函数、类型转换、非确定性函数（如
NOW()）、子查询、或引用了非索引列的表达式 - 开启 ICP 不需要手动配置，默认启用（MySQL 5.6+），但存储引擎必须支持——
InnoDB和MyISAM支持，Memory不支持
EXPLAIN 里看到 Using index condition 就一定有收益？
不一定。ICP 的实际效果取决于过滤强度和回表代价。如果下推的条件过滤率很低，或者索引本身已经非常窄（比如唯一索引 + 等值查询），ICP 带来的优化几乎不可见。
- 高收益场景：联合索引前缀匹配后，后续列有高选择性范围查询，例如
INDEX (status, create_time, user_id)上执行WHERE status = 'active' AND create_time > '2024-01-01' - 低收益甚至负向场景：下推的是低选择性条件（如
gender = 'M'），或索引覆盖了所有查询字段（即Using index），此时根本不需要回表，ICP 无用武之地 - 注意
key_len：它只反映索引最左匹配长度，不体现 ICP 下推了多少列；要确认下推行为，得结合Extra和实际Handler_read_*状态变量对比
联合索引顺序怎么影响 ICP 能否生效？
ICP 只能对索引中“已定位到的连续前缀之后”的列生效。也就是说，必须先用上索引最左的若干列做范围/等值查找，后面的列才能参与下推。
- 索引
(a, b, c)，查询WHERE a = 1 AND c = 3：只有a = 1用于定位，c = 3无法下推（b没出现在条件中，中断了连续性） - 索引
(a, b, c)，查询WHERE a = 1 AND b > 10 AND c = 5：三者都可能下推，因为a和b构成有序扫描区间，c是紧随其后的索引列 - 索引
(a, b, c)，查询WHERE a = 1 AND b = 2 ORDER BY c LIMIT 10：ICP 对c依然有效，但排序和分页逻辑不影响下推判断
ICP 和索引覆盖、MRR 有什么关系？
它们是正交优化机制，可叠加生效，但解决的问题不同：
- 索引覆盖（
Using index）：避免回表，靠索引本身存全所需字段 - MRR（Multi-Range Read）：把随机回表变成顺序读，靠
read_rnd_buffer_size缓冲批量主键再排序读取 - ICP：在索引 B+ 树叶子节点遍历时，提前用部分条件过滤掉不满足的索引记录，减少回表请求次数
- 三者共存时，执行计划
Extra可能同时出现Using index condition、Using index、Using MRR—— 这是理想状态，不是冲突
真正容易被忽略的是：ICP 不会改变索引扫描的起始和结束位置，它只在“已扫到的索引项”上做二次筛选。所以即使启用了 ICP，如果索引选择不当导致扫描范围过大，性能瓶颈仍在扫描本身，而非过滤逻辑。
