MySQL查询时，WHERE、ORDER BY、GROUP BY等操作全在Server层完成，数据定位、B+树遍历、回表等由存储引擎层执行；Server层通过调用引擎接口并传入table->record[0]地址实现单向指令式交互，引擎将数据按指定格式“填空”写入该内存区域。
MySQL执行一条查询时，WHERE条件过滤、ORDER BY排序、GROUP BY聚合这些操作全在Server层完成；而数据从磁盘或Buffer Pool里读哪一页、按B+树怎么定位记录、是否要回表——这些都由存储引擎层决定。两者不是协同“商量”，而是Server层发指令、引擎层交结果的单向调用关系。
Server层如何把查询意图传给InnoDB？
执行器拿到优化器生成的执行计划后，会逐行调用存储引擎接口（比如ha_innobase::index_read()或ha_innobase::rnd_next()），每次只申请一条记录的空间。关键在于：table->record[0]这个内存地址会被传给InnoDB，引擎读到数据后，必须按Server层定义的字段偏移（Field::ptr）和格式，把值写进这块内存里。不是返回一个结构体，而是“填空”式写入。
- 如果字段是
VARCHAR，InnoDB还要先写长度字节（1或2字节），再写内容 -
record[0]和record[1]大小等于该表“最大行长度”，哪怕实际只用了20字节，也得预留足够空间 - 字段类型不匹配（比如Server层认为是
TINYINT，InnoDB返回了4字节整数）会导致WHERE判断出错或崩溃
为什么EXPLAIN里的type=range不等于InnoDB只读一次磁盘？
type=range只是Server层对执行计划的描述，它不控制InnoDB内部行为。InnoDB仍需按索引B+树结构逐页遍历叶子节点，每读一条满足范围条件的记录，就填一次record[0]，然后返回给Server层做WHERE二次过滤（如果还有其他非索引条件）。这意味着：即使SQL写了WHERE create_time BETWEEN ... AND ...，只要create_time上有索引，InnoDB负责快速定位起点，但Server层仍可能丢弃其中部分记录。
- 例如
WHERE create_time BETWEEN ? AND ? AND status = 1，status没索引，InnoDB无法跳过，只能全扫范围内的索引项 - InnoDB返回的每条记录都经过
handler::ha_rnd_next()或handler::index_read()调用，开销不可忽略 - Buffer Pool命中率低时，
range扫描可能触发大量随机I/O，而Server层完全感知不到
Server层和引擎层之间没有缓存共享，只有数据拷贝
Server层的JOIN缓冲区、GROUP BY临时表、ORDER BY排序缓冲区，和InnoDB的Buffer Pool是两套独立内存管理机制。InnoDB从磁盘读一页进Buffer Pool，Server层要某条记录时，InnoDB还得把那行数据从Buffer Pool里解析出来，再拷贝进table->record[0]。不存在“指针引用”或“零拷贝”——这是插件架构的代价。
- 大字段（如
TEXT）可能被InnoDB单独存为外部页，Server层读取时触发额外I/O -
SELECT *会强制InnoDB回表（如果走二级索引），而Server层对“回表”无感知，只看到handler::index_read()返回了一条完整记录 - 如果你在
performance_schema里看到wait/io/file/innodb/innodb_data_file等待高，问题大概率不在SQL写法，而在Server层与引擎层之间数据搬运太频繁
真正容易被忽略的是：Server层永远不知道InnoDB内部用了多少页、是否触发了自适应哈希、有没有因为锁等待而暂停。它只认HA_ERR_KEY_NOT_FOUND或HA_ERR_LOCK_WAIT_TIMEOUT这类错误码。调优时盯着EXPLAIN和slow log远远不够，得结合INFORMATION_SCHEMA.INNODB_METRICS看引擎真实负载。
