Server层不直接传递WHERE条件，而是通过调用InnoDB接口（如index_read或rnd_next）发送粗粒度指令，InnoDB将匹配记录按Server层定义的字段格式（含偏移、长度字节、NULL标志）填入table->record[0]内存区；非索引条件由Server层二次过滤，类型不匹配会导致错判或崩溃。
Server层怎么把WHERE条件传给InnoDB
Server层不直接告诉InnoDB“过滤status = 1”，而是发一个粗粒度指令，比如ha_innobase::index_read()或ha_innobase::rnd_next()，让引擎返回下一条记录。InnoDB读出数据后，填进table->record[0]这块固定大小的内存里——字段顺序、偏移量、长度字节（VARCHAR要先写1~2字节长度）、NULL标志位，全按Server层定义的格式来。
常见错误现象：字段类型定义不一致，比如建表时status TINYINT，但应用层误用INT写入，InnoDB返回4字节整数，Server层按1字节解析，后续WHERE status = 1就可能错判甚至崩溃。
- Server层只负责“填空”，不负责校验字段内容是否越界
- 所有非索引条件（如
WHERE name LIKE '%abc%' AND status = 1）都必须由Server层自己过滤，InnoDB无法跳过 - 即使
status上有索引，只要没出现在ORDER BY或GROUP BY中，InnoDB也不会主动利用它做定位
为什么EXPLAIN显示type=range，InnoDB却要读很多页
type=range只是Server层对执行计划的描述，代表它打算用索引范围扫描；但它不控制InnoDB内部怎么读。InnoDB仍需按B+树结构逐页遍历叶子节点，每找到一条满足create_time BETWEEN ? AND ?的记录，就调一次handler::index_read()，填一次record[0]，再返回给Server层。
如果还有额外条件（如AND deleted = 0），而deleted没索引，InnoDB无法跳过那些create_time在范围内但deleted = 1的记录——它得全读出来，交由Server层二次过滤。
- Buffer Pool命中率低时，每次
index_read()都可能触发一次随机I/O - Server层完全感知不到磁盘读压力，
Created_tmp_tables或Sort_merge_passes飙升才是它“扛不住”的信号 -
EXPLAIN里的rows是Server层估算值，实际InnoDB扫描的记录数可能多出几倍
SELECT *和SELECT id在交互上有什么本质区别
区别不在SQL写法，而在Server层是否能避免回表。当SELECT id且id是主键或覆盖索引的一部分时，Server层会判断“不需要完整行”，于是调用index_read()并告知InnoDB：只读索引页里的字段值即可。InnoDB这时不访问聚簇索引，直接从二级索引叶子节点取id填入record[0]。
而SELECT *意味着Server层明确要求“整行数据”，InnoDB必须先定位索引项，再根据主键去聚簇索引里回表查完整记录，最后按字段定义挨个拷贝进record[0]——这个过程涉及两次B+树查找、更多内存拷贝、更大网络包。
- 覆盖索引是否生效，取决于Server层能否识别并下推“只读索引列”的意图
- InnoDB不主动判断哪些字段被需要，它只响应Server层传来的
read_set位图（标记哪些字段要读） - 如果表有TEXT/BLOB字段，
SELECT *还可能触发额外的外部存储页读取，Server层对此无感知
事务隔离级别如何影响这一交互
Server层在事务开启时创建一致性视图（read_view），并在每次调用ha_innobase::index_read()时把它透传给InnoDB。InnoDB的row_search_mvcc()函数据此决定：该返回哪个版本的记录、是否可见、是否要构造undo记录。
关键点在于：Server层不参与MVCC版本判断，它只说“我要id=123这行”，具体哪条版本由InnoDB按当前read_view裁决。如果Server层漏传或复用旧视图（比如长事务未及时更新），就会出现幻读或不可重复读——这不是SQL写错了，而是两层间视图同步出了问题。
- RC隔离级下，每次
SELECT都会新建read_view；RR下复用事务开启时的那个 - Server层不保存历史版本，所有版本管理、undo链遍历、purge协调全在InnoDB内完成
- 锁（如
SELECT ... FOR UPDATE）也是Server层传参触发，但加锁逻辑、锁冲突检测、死锁回滚全部由InnoDB执行
record[0]填充都是内存拷贝，不是指针引用；Buffer Pool里的页和Server层的JOIN缓冲区、排序缓冲区完全隔离。优化慢查时，盯着Handler_read_*状态变量比只看EXPLAIN更接近真相。 
