索引下推（icp）在mysql 8.0默认开启但需满足条件才生效：仅对innodb二级索引有效，要求where部分谓词能仅用索引列判断，explain显示“using index condition”才确认生效。
索引下推（ICP）在 MySQL 8.0 中默认开启，但不等于自动生效
ICP 是否起效，取决于查询条件能否被“下推到存储引擎层”执行，而不是由 Server 层过滤。它只对 InnoDB 的二级索引有效，且必须满足「WHERE 条件中部分谓词能仅用索引列完成判断」这一前提。
常见误判是：建了联合索引就以为 ICP 自动工作。实际上，如果查询中包含 LIKE '%abc'、函数调用（如 UPPER(name)）、或引用子查询，ICP 就会被绕过。
-
EXPLAIN的Extra列出现Using index condition才表示 ICP 生效；若只有Using where，说明条件全在 Server 层过滤，回表后才判断 - 联合索引顺序很重要：
CREATE INDEX idx_cat_price ON products(category, price)支持WHERE category='x' AND price 下推；但 <code>WHERE price 单独出现时，ICP 不触发（无法跳过 <code>category） - 虚拟生成列上的二级索引不支持 ICP，即使语法合法，
EXPLAIN也不会显示Using index condition
如何验证 ICP 是否真正减少了 IO？
不能只看 EXPLAIN，要结合实际 IO 行为观测。InnoDB 的 Handler_read_* 状态变量比 rows 更可信：
-
SHOW STATUS LIKE 'Handler_read%';执行前后对比，重点关注Handler_read_next（索引遍历次数）和Handler_read_rnd_next（回表读行次数） - ICP 生效时，
Handler_read_rnd_next应显著低于未下推时 —— 因为很多不满足price 的索引项，在引擎层就被筛掉了，根本不会触发回表 - 注意：
Handler_read_first和Handler_read_key变化不大，它们反映索引定位开销，ICP 不减少这部分
哪些 WHERE 条件会被拒绝下推？
ICP 对表达式类型敏感，不是所有带索引列的条件都能下推。以下情况会退回到 Server 层过滤：
- 涉及子查询：
WHERE price > (SELECT AVG(price) FROM products) - 调用存储函数或内置函数：
WHERE YEAR(created_at) = 2024或WHERE LENGTH(name) > 10 - 使用非确定性函数：
NOW()、RAND()等 - 列与列比较：
WHERE price > cost（哪怕price和cost都在索引里） - 模糊匹配左通配：
WHERE name LIKE '%john'——LIKE 'john%'可下推，但%john不行
覆盖索引和 ICP 不是替代关系，而是配合使用
覆盖索引（Using index）目标是「完全避免回表」；ICP 目标是「减少无效回表」。两者常叠加使用，但优先级不同：
- 如果查询字段全在索引中（如
SELECT category, price FROM products WHERE category='x' AND price ），优化器优先走覆盖索引，<code>EXPLAIN显示Using index，此时 ICP 不再起作用（没回表可减） - 如果查询需要额外字段（如
SELECT * FROM products WHERE category='x' AND price ），则 ICP 发挥价值：先用索引过滤掉大量不满足 <code>price的主键，再回表取完整行 - 实践中，应先按业务高频查询设计覆盖索引；对仍需回表的场景，再检查 ICP 是否生效 —— 不要为了 ICP 而刻意拆分索引
真正容易被忽略的是：ICP 效果高度依赖数据分布。当筛选条件过滤率很低（比如 price 匹配 95% 行），下推带来的 IO 减少微乎其微，此时优化重点该转向索引选择性或查询逻辑重构。
