MySQL执行器通过handler接口层调用InnoDB读取逻辑，如ha_index_read()和ha_rnd_next()，实际进入引擎注册的虚函数实现；“Using index”时可能绕过这些接口直接从索引页提取数据。
MySQL执行器怎么触发InnoDB的读取逻辑
执行器不直接调用存储引擎，而是通过 handler 接口层中转。每个表对象（TABLE）持有一个 handler 实例，执行器调用 ha_index_read()、ha_rnd_next() 这类函数时，实际进入的是引擎注册的虚函数实现——比如 InnoDB 的 ha_innobase::index_read()。
常见错误现象：你在调试时断点打在 handler::index_read() 却没命中，其实是被派发到了具体引擎子类；或者看到 ha_rnd_next() 返回 HA_ERR_END_OF_FILE 但表明明有数据——这往往是因为 ha_rnd_init() 没成功，或事务隔离级别导致可见性为空。
-
ha_rnd_next()对应全表扫描，但只有在没有可用索引、或优化器选了ALL访问类型时才走这条路 -
ha_index_read()和ha_index_next()是索引扫描主力，注意find_flag参数控制“等于/大于/大于等于”语义 - InnoDB 的
handler实现里，多数操作会先检查prebuilt->trx是否有效，事务未开启或已回滚会导致直接返回错误 - MyISAM 的
handler不需要事务上下文，但不支持 MVCC，ha_rnd_next()可能读到未提交脏数据（如果用了 LOCK TABLES）
为什么 EXPLAIN 显示 Using index 却没进 ha_index_read
“Using index” 表示覆盖索引，执行器可能压根不调用引擎的行读取接口——它从索引 B+ 树的页内直接提取字段值，走的是 key_copy() + key_cmp() 路径，绕过了 ha_index_read() 的完整记录构造流程。
典型场景：你定义了联合索引 (a,b,c)，查询 SELECT a,b FROM t WHERE a=1，优化器发现所有字段都在索引里，就会让执行器从索引节点直接拷贝 a 和 b，不触发引擎层的记录解包。
- 这种优化只对存储引擎支持“索引元组解析”的情况生效（InnoDB 支持，MyISAM 不支持）
- 一旦 SELECT 中包含非索引字段（如
c是 TEXT 类型且不在索引中），就必须调用ha_index_read()去聚簇索引回表 - 调试时若想强制走引擎读取路径，可加
FORCE INDEX并确保 SELECT 列超出索引覆盖范围
handler::external_lock() 被反复调用却没报错，是正常行为吗
是正常行为。这个函数不是“加锁”动作本身，而是通知引擎“当前线程即将访问这张表”，InnoDB 实际上只用它来维护 prebuilt->trx 和锁等待队列的绑定关系。每条 SQL 开始前执行器都会调一次 external_lock(LOCK_TABLE_READ) 或 LOCK_TABLE_WRITE，SQL 结束时再调一次 external_lock(UNLOCK_TABLE)。
容易踩的坑：如果你在自定义 UDF 或插件里手动调用了 handler 接口，但忘了配对调用 external_lock()，InnoDB 可能复用上一个语句的事务上下文，导致锁冲突或主键冲突误报。
- DDL 操作（如
ALTER TABLE）期间，external_lock()会升级为LOCK_TABLE_WRITE，此时其他连接的SELECT会被阻塞（取决于lock_wait_timeout） - XA 事务中，
external_lock()还要参与两阶段提交的状态同步，失败会导致XAER_RMFAIL - 不要在循环里反复打开/关闭同一张表的
handler，每次都会触发两次external_lock()，增加锁管理开销
MySQL 8.0 后 handler 接口变化最影响兼容性的点
最关键的变动是 handler::records_in_range() 的签名变更：8.0.26 起，该函数必须返回精确行数估计，且参数 min_key/max_key 的长度不再由调用方传入，改由引擎自己从 key_part 结构推导。老版本驱动或存储引擎插件若仍按旧方式解析 key buffer，大概率触发越界读或断言失败。
另一个隐蔽问题：handler::multi_range_read_info_const() 在 8.0.30 后要求必须实现，否则优化器禁用 MRR（Multi-Range Read）优化，全表扫描性能骤降。
- 升级前务必检查引擎是否重写了
records_in_range()，尤其注意key_length字段是否被忽略 -
multi_range_read_init()和multi_range_read_next()必须成对存在，否则EXPLAIN里看不到Using MRR - 8.0.33 开始，
handler::rnd_pos()已标记为废弃，新引擎应优先实现rnd_pos_by_rowid()，否则在启用innodb_read_only时可能无法定位记录
Handler API 看似是执行器和引擎之间的胶水层，但它把事务生命周期、锁策略、索引结构差异都揉进了几十个虚函数里。最常被忽略的是：同一个 handler 实例可能被多个执行线程并发调用，而它的成员变量（比如 prebuilt）并不是线程安全的——InnoDB 靠的是每个语句独占一个 prebuilt，而不是靠锁保护 handler 本身。
