索引下推（ICP）是MySQL 5.6+默认启用的优化机制，将WHERE中涉及索引列的条件下推至存储引擎层执行，减少回表次数和I/O开销；仅适用于InnoDB二级索引及MyISAM表，不支持聚簇索引、分区表（5.6）、虚拟生成列索引、子查询或函数条件。
table->record[0] 是唯一真实的交互契约，不是“取数据”，而是“填内存”。
执行器传给InnoDB的到底是什么？
执行器调用 ha_innobase::index_read() 或 ha_innobase::rnd_next() 时，核心参数只有一个：table->record[0]——一个指向内存块的指针。InnoDB 不返回结构体、不构造对象，只把读到的行按字段偏移（Field::ptr）和格式原地写进去。
- 这个内存块大小 = 表定义的最大行长度（哪怕实际只存了几个字节）
- VARCHAR 字段先写 1–2 字节长度头，再写内容；INT 写 4 字节；类型错配（比如 Server 层认为是
TINYINT，InnoDB 写了 4 字节）会导致 WHERE 条件误判甚至崩溃 - Server 层完全不知道 InnoDB 是否从磁盘读、是否命中 Buffer Pool，也不共享任何缓存状态
为什么 WHERE 条件没走索引，InnoDB 还要吐一堆无效行？
InnoDB 只负责按 B+ 树定位起始位置和范围，不理解 SQL 语义。例如 WHERE create_time BETWEEN ? AND ? AND status = 1，若 status 无索引，InnoDB 就得把整个时间范围内所有行都填进 table->record[0]，再交给 Server 层逐行过滤。
-
EXPLAIN显示type=range≠ InnoDB 只扫一次磁盘，它可能返回上千行，但其中 99% 被 Server 层丢弃 - 每次
rnd_next()或index_read()调用都有开销；Buffer Pool 命中率低时，触发大量随机 I/O - 想减少无效传输？只有
ICP（Index Condition Pushdown）能下推部分条件到 InnoDB 层，且仅对索引列生效
ICP 到底优化了什么，又不能做什么？
MySQL 5.6+ 启用 ICP 后，联合索引 (a,b) 上执行 WHERE a LIKE '99%' AND b = 'd'，InnoDB 可在索引页内直接跳过 b != 'd' 的项，避免把它们填进 table->record[0]。
- 没 ICP 时：InnoDB 返回所有
a LIKE '99%'的索引项，Server 层再判断b - ICP 不处理回表后的字段（比如
SELECT *中非索引列），那些仍得 Server 层过滤 - ICP 是否启用取决于优化器决策，可通过
optimizer_switch='index_condition_pushdown=on'控制
真正容易被忽略的底层事实
Server 层和 InnoDB 之间没有共享内存、没有联合缓存、没有状态协商——只有单向指令与填空式交付。InnoDB 不“响应查询”，它只是按地址覆写内存；执行器不“拉数据”，它只是预留好一块内存让引擎来填。
任何把交互想象成“发 SQL → 引擎吐结果”的直觉，都会在分析慢查询、排查崩溃或调试 ICP 失效时掉进坑里。
