SELECT 1 不走存储引擎但完整执行 MySQL Server 层流程：连接器权限校验、解析器生成语法树、优化器生成执行计划、执行器常量求值，且受 SQL_MODE 和字符集影响。
SELECT 1 不走存储引擎，但其他流程一个不少 —— 它是验证 MySQL Server 层是否正常工作的最小闭环。
连接器必须先完成权限校验
哪怕只是 SELECT 1，MySQL 也会走完整连接流程：TCP 握手 → 用户名密码验证 → 权限加载。如果账号没被授予 USAGE 权限（即最低限度的连接权），照样报错 Access denied for user。注意：权限是在连接建立时一次性读入内存的，后续改权限对已存在的连接无效。
查询缓存早被移除，别白费力气配
MySQL 8.0+ 已彻底删除查询缓存模块，SELECT 1 不会触发任何缓存逻辑。如果你在 8.0 环境下还看到 query_cache_type = ON 或相关参数，它们已失效，且启动时会警告。旧版本（如 5.7）虽支持，但因表一更新就全失效，实际对 SELECT 1 这类无表查询也无意义。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
解析器和优化器照常工作，但极快
- 解析器会把
SELECT 1拆成 token：SELECT、1，生成合法语法树；不存在字段或表名歧义问题，所以不会卡在预处理阶段 - 优化器不需选索引、不需决定 JOIN 顺序，但它仍会生成执行计划 —— 你可以用
EXPLAIN SELECT 1看到select_type: SIMPLE、table: NULL、rows: 1，说明它明确识别出这是无表查询 - 执行器直接调用内置常量求值逻辑，不向存储引擎发任何请求；
SELECT 1 FROM DUAL和SELECT 1在行为上完全等价，DUAL只是兼容 Oracle 的占位符，InnoDB 根本不参与
执行器返回结果前会检查 SQL_MODE 和字符集
看似简单的 SELECT 1，仍受当前会话的 sql_mode 和 character_set_results 影响：
- 若启用了
STRICT_TRANS_TABLES，不影响结果；但若误设了ERROR_FOR_DIVISION_BY_ZERO等无关模式，也不会报错 —— 因为没涉及除零 - 返回值类型是
INT，但最终传输给客户端的字节流编码由character_set_results控制；比如设为utf8mb4时，数字1仍以 ASCII 字节0x31发送，但字段元数据中标明了字符集，客户端据此决定如何解析字段名（如1列的别名） - 如果客户端连接时未声明
charset，且服务端collation_server是utf8mb4_0900_as_cs，SELECT 1的响应头仍会携带该排序规则信息，虽不影响数值本身
真正容易被忽略的是：这个“最简查询”全程不碰磁盘、不申请 buffer pool、不触发 InnoDB 的事务状态检查，但它真实暴露了 Server 层各组件的耦合关系 —— 少一个环节（比如连接器拒绝认证），整条链就断在第一步。
