MySQL Server层与存储引擎层协作本质是“发指令→填内存→交结果”：Server层不读.ibd文件、不解析SQL，仅负责解析优化、调用引擎接口并二次过滤；InnoDB只按指定内存布局（table->record[0]）填空返回数据，不参与SQL逻辑判断。
Server层不读数据文件，InnoDB不解析SQL——协作本质是“发指令→填内存→交结果”，不是共同干活。
Server层只管发指令，不碰.ibd文件
Server层完全不知道数据存在哪块磁盘、用什么格式存。它只做三件事：确认怎么查（优化器）、告诉引擎查什么（执行器调用ha_innobase::index_read()或ha_innobase::rnd_next()）、拿到数据后自己过滤排序。哪怕你写了SELECT * FROM orders WHERE status = 'paid'，只要status没索引，Server层就只能让InnoDB把整张表扫一遍，再自己逐行比对status值。
- 所有SQL语法校验、函数计算（如
DATE(created_at)）、JOIN顺序、GROUP BY分组都在Server层完成 - Server层传给InnoDB的是一组“要求”：比如“按主键找id=123那行”或“从索引
idx_time里扫2023-01-01到2023-12-31之间的叶子节点” - InnoDB返回的不是“记录对象”，而是把字段值按
table->record[0]的内存布局原样塞进去——字段偏移、长度字节、字符集转换全由Server层定义，InnoDB照填
InnoDB只负责“填空”，不决定WHERE是否生效
很多人误以为EXPLAIN里显示type=range就代表InnoDB内部只读一次磁盘。其实不是：InnoDB按B+树结构一页一页往下找，每找到一条满足索引范围的记录，就调用一次handler::index_read()，把那行数据填进record[0]，然后立刻交还给Server层。Server层收到后，再拿WHERE里其余条件（比如AND user_id > 1000）做二次过滤。
- 如果
WHERE里有无法下推的条件（如UPPER(name) = 'ABC'），InnoDB根本不管，全量返回，Server层自己判 - 即使走了覆盖索引，Server层也得检查
record[0]里字段是否真被索引包含——这个判断靠的是key_info元数据，不是InnoDB主动告知 -
ORDER BY能用索引时，Server层会要求InnoDB按索引顺序返回；但如果ORDER BY a, b而索引只有(a)，Server层就得自己开sort_buffer_size内存排序
两层之间零共享缓存，拷贝开销真实存在
Buffer Pool和Server层的JOIN缓冲区、临时表、排序内存完全是两套独立系统。InnoDB从磁盘读一页进Buffer Pool，Server层要其中某条记录时，InnoDB还得把那行从Buffer Pool里解析出来，再逐字段拷贝进table->record[0]。这个过程不经过任何缓存加速。
- 宽表（比如50列）+大量结果集（
LIMIT缺失）→handler::rnd_next()调用次数爆炸，CPU和内存带宽都吃紧 - 字符集不一致（如表用
utf8mb4，客户端连接用latin1）→Server层在拷贝时强制转码，额外开销 - 事务一致性视图由Server层创建并透传给InnoDB，漏传或复用旧视图会导致RC隔离级下读到不该读的数据
真正卡顿的地方往往不在SQL写得有多差，而在于Server层和InnoDB之间“填空”动作太频繁、拷贝太宽、过滤太晚。看SHOW PROFILE里的Copying to tmp table或Sorting result高，基本就是Server层在兜底；而Handler_read_next飙升，说明InnoDB正在反复填空——这时候该想的不是加索引，而是减少Server层需要处理的行数。
