执行器是SQL执行阶段的核心组件，负责按执行计划调用存储引擎接口完成数据操作，并在校验字段级权限、处理锁冲突、协调多引擎JOIN、响应事务隔离级别等方面起关键作用。
执行器是SQL真正干活的“操作员”
执行器不解析语法、不选索引、不验权限（权限已在连接器阶段缓存，但执行器会再做一次校验），它只干一件事：按优化器生成的执行计划，调用存储引擎接口，把数据读出来、写进去、删掉或改掉，并把结果组装好返回给客户端。
执行器为什么还要再查一次权限？
因为权限缓存在连接器阶段只读取一次，而执行器面对的是具体表和字段——比如你有
权限，但没被授予对
字段的访问权，执行器在真正访问该字段时就会报错：
权限检查发生在打开表之后、读取数据之前
即使
语句能通过分析器，执行器仍可能因字段级权限不足而中断
视图、触发器、存储过程内部的 SQL，其字段权限也由执行器动态校验
执行器如何与存储引擎协作？
执行器本身不存数据，它只调用统一接口，具体行为由表使用的存储引擎决定：
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
对
表：执行器调用
或
等接口，走聚簇索引或二级索引扫描
对
表：执行器调用内存哈希/树结构接口，无磁盘 I/O
如果 SQL 中涉及多个引擎（如 JOIN
和
表），执行器需分别调用各自引擎 API，协调数据流转
遇到锁冲突（如行锁等待）、事务隔离级别限制（如不可重复读下看到旧版本），也是执行器层感知并响应
容易被忽略的执行器行为细节
很多慢查询或报错看似在“查不到数据”，其实卡在执行器阶段：
在执行器尝试加锁时阻塞，不是优化器问题，也不是
网络问题
执行器发现表不存在（
）是在打开表时才报，而非分析器阶段——因为表名可能来自变量或视图展开
使用
后仍走错索引？那大概率是执行器已拿到计划，但存储引擎实际执行时因统计信息过期或锁状态绕开了预期路径
执行器返回结果前会做字符集转换、时间戳时区调整、NULL 处理等——这些开销在
的
阶段体现，不是纯 I/O
执行器表面只是“执行”，但它才是整个流程里最贴近真实数据、最常暴露权限/锁/引擎差异的环节。调试时别只盯着
，要配合
和
看它到底卡在哪一步。
SELECTusers.phoneERROR 1142 (42000): SELECT command denied to user 'app'@'%' for column 'phone' in table 'users'SELECT *InnoDBha_innobase::rnd_next()index_read()MemoryInnoDBMyISAMSELECT ... FOR UPDATEERROR 1146 (42S02)FORCE INDEXSHOW PROFILESending dataEXPLAINSHOW PROFILE FOR QUERY NINFORMATION_SCHEMA.INNODB_TRX