mysql 5.6+默认启用icp，但仅当查询走二级索引、条件含索引中可下推的简单谓词（如=、>、like'prefix%'）、且优化器判定代价更低时才生效，explain中显示“using index condition”即触发。
MySQL 5.6+ 默认启用索引下推（ICP），但只有满足特定条件时才会真正生效——不是建了复合索引就自动触发，更不会对所有 WHERE 条件都下推。
哪些查询能触发 Using index condition
ICP 只在存储引擎层能直接计算的条件下工作，且必须走二级索引 + 回表路径。常见有效场景：
-
WHERE中包含复合索引的**连续前缀列 + 后续列的简单过滤**，例如索引为KEY idx_name_age (name, age)，查询WHERE name = 'Zhang' AND age > 25 - 支持
LIKE 'prefix%'（前缀匹配），如name LIKE 'Li%'，但不支持'%Li'或'%Li%' - 范围条件如
age BETWEEN 20 AND 30、score > 85，只要字段在索引中且类型匹配 - 访问类型必须是
ref、range、eq_ref或ref_or_null；ALL（全表扫描）或index（全索引扫描）不触发 ICP
执行 EXPLAIN SELECT ... 后，若 Extra 列出现 Using index condition，说明 ICP 已介入；若只有 Using where，则过滤仍在 Server 层完成。
为什么 UPPER(name) = 'LI SI' 或 MONTH(birthdate) = 3 不会下推
ICP 要求条件能在存储引擎层“无上下文”地计算，即不依赖函数求值、类型转换或外部数据。以下写法会直接禁用 ICP：
- 任何函数调用：
UPPER(name)、DATE(birthdate)、CONCAT(lastname, firstname) - 隐式类型转换：索引列为
VARCHAR，却写成WHERE zipcode = 431200（数字字面量） - 子查询：
WHERE age > (SELECT AVG(age) FROM user) - 涉及非索引列的表达式：
WHERE age + score > 100（即使age和score都在索引里）
这类条件会被 Server 层接管，导致原本可下推的部分也被拉回上层过滤，回表次数陡增。
联合索引设计如何配合 ICP 发挥最大效果
ICP 不是独立优化项，它高度依赖索引结构与查询模式的对齐。关键点：
- 把**高选择性、常用于等值或前缀匹配的列放最左**（如
status、tenant_id），确保能快速定位索引区间 - 将**可能参与范围/模糊匹配的列紧随其后**（如
created_at > '2025-01-01'、name LIKE 'Zhang%'），它们才可能被下推 - 避免在索引中间插入低选择性列（如
gender），否则后续列大概率无法利用，ICP 也失效 - 不要为了 ICP 强行加冗余列——如果查询从不单独用
age，但总和name一起查，(name, age)就比(age, name)更合理
示例：索引 idx_zip_city (zipcode, city) 对 WHERE zipcode = '100001' AND city LIKE 'Bei%' 有效；但对 WHERE city = 'Beijing' 完全无效（跳过最左列，索引根本不用）。
容易被忽略的配置与陷阱
ICP 默认开启，但某些操作会绕过它：
- 显式使用
FORCE INDEX时，ICP 仍可能生效，但若该索引本身不覆盖全部过滤字段，Server 层仍需补过滤——别以为加了FORCE就万事大吉 - 分区表上 ICP 支持有限，尤其当条件跨多个分区时，下推逻辑可能退化
- InnoDB 表上，ICP **只对二级索引有效**；主键索引（聚簇索引）本身不回表，自然无“下推减少回表”一说
- 用
optimizer_switch='index_condition_pushdown=off'关闭 ICP 后，EXPLAIN中Using where会变多，回表数上升，但有时反而利于调试真实过滤开销
最常被忽视的一点：ICP 的收益取决于**被过滤掉的索引记录占比**。如果 name = 'Zhang' 找到 1000 条索引项，而 age > 25 能筛掉其中 900 条，ICP 就非常值；但如果只筛掉 10 条，优化意义就很有限——得看实际数据分布，不能只盯执行计划里的 Using index condition。
