执行器是SQL执行阶段的核心组件，负责按执行计划调用存储引擎接口完成数据操作，并在校验字段级权限、处理锁冲突、协调多引擎JOIN、响应事务隔离级别等方面起关键作用。

执行器是SQL真正干活的“操作员”

执行器不解析语法、不选索引、不验权限（权限已在连接器阶段缓存，但执行器会再做一次校验），它只干一件事：按优化器生成的执行计划，调用存储引擎接口，把数据读出来、写进去、删掉或改掉，并把结果组装好返回给客户端。

执行器为什么还要再查一次权限？

因为权限缓存在连接器阶段只读取一次，而执行器面对的是具体表和字段——比如你有 SELECT 权限，但没被授予对 users.phone 字段的访问权，执行器在真正访问该字段时就会报错：

ERROR 1142 (42000): SELECT command denied to user 'app'@'%' for column 'phone' in table 'users'

• 权限检查发生在打开表之后、读取数据之前
• 即使 SELECT * 语句能通过分析器，执行器仍可能因字段级权限不足而中断
• 视图、触发器、存储过程内部的 SQL，其字段权限也由执行器动态校验

执行器如何与存储引擎协作？

执行器本身不存数据，它只调用统一接口，具体行为由表使用的存储引擎决定：

• 对 InnoDB 表：执行器调用 ha_innobase::rnd_next() 或 index_read() 等接口，走聚簇索引或二级索引扫描
• 对 Memory 表：执行器调用内存哈希/树结构接口，无磁盘 I/O
• 如果 SQL 中涉及多个引擎（如 JOIN InnoDB 和 MyISAM 表），执行器需分别调用各自引擎 API，协调数据流转
• 遇到锁冲突（如行锁等待）、事务隔离级别限制（如不可重复读下看到旧版本），也是执行器层感知并响应

容易被忽略的执行器行为细节

很多慢查询或报错看似在“查不到数据”，其实卡在执行器阶段：

• SELECT ... FOR UPDATE 在执行器尝试加锁时阻塞，不是优化器问题，也不是网络问题
• 执行器发现表不存在（ERROR 1146 (42S02)）是在打开表时才报，而非分析器阶段——因为表名可能来自变量或视图展开
• 使用 FORCE INDEX 后仍走错索引？那大概率是执行器已拿到计划，但存储引擎实际执行时因统计信息过期或锁状态绕开了预期路径
• 执行器返回结果前会做字符集转换、时间戳时区调整、NULL 处理等——这些开销在 SHOW PROFILE 的 Sending data 阶段体现，不是纯 I/O