预处理器通过查询information_schema.tables和information_schema.columns校验表名与列名是否存在且可访问，发生在解析后、优化前；若表或字段不存在，直接报error 1054或1146并终止执行，不进入后续阶段。
预处理器查表名和列名，靠的是information_schema
MySQL预处理器不是靠猜，而是直接查系统元数据。它会访问information_schema.tables和information_schema.columns这两张视图，确认SQL里写的表、库、字段是否真实存在且可访问。
这个过程发生在解析器生成语法树之后、优化器介入之前。也就是说，哪怕SQL语法完全合法（比如SELECT name FROM users），只要users表不存在或name字段拼错，预处理器就会立刻报错，不会走到执行阶段。
- 查表时，会比对
table_schema（库名）、table_name；如果库没指定，默认用当前USE的库 - 查列时，不仅核对
column_name，还会检查该列是否属于目标表——不支持跨表模糊匹配 - 视图会被递归展开，预处理器会一层层查到底层基表的字段定义
- 大小写敏感：Linux下
users和USERS是两个不同表，检查严格区分
ERROR 1054 和 ERROR 1146 是预处理器抛出的典型错误
ERROR 1054 (42S22): Unknown column 'xxx' in 'field list' 和 ERROR 1146 (42S02): Table 'db.xxx' doesn't exist 都来自预处理阶段，不是语法错误，也不是运行时异常。
它们的区别很明确：1054说明表存在但字段不对，1146说明连表都找不到。这两个错误一旦触发，SQL就终止，后续任何逻辑（比如IFNULL、CASE、存储过程里的DECLARE HANDLER）都来不及执行。
- ORM用户容易误判：Django的
models.py字段名和db_column不一致、Laravel模型里$fillable漏字段，都会导致1054 - MyBatis用户要注意：Mapper XML里写的字段名，和实际数据库字段名必须完全一致，别信IDE自动补全
- 别试图用
IFNULL(missing_col, 'fallback')兜底——字段不存在，SQL根本过不了预处理，函数压根不会被调用
长连接下元数据缓存可能让预处理“看错”表结构
预处理器依赖information_schema，而MySQL会对这部分元数据做轻量缓存。在长连接场景中，如果表结构刚被ALTER TABLE修改过，旧连接可能还在用缓存的旧定义，导致预处理器误报ERROR 1054或ERROR 1146。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
这不是bug，是设计使然。MySQL不会为每个查询都刷新元数据，否则性能损耗太大。
- 临时解决：执行
FLUSH TABLES强制刷新当前连接的表缓存 - 更稳妥做法：在DDL后主动断开并重建连接，尤其在部署脚本或迁移任务中
- 注意
SQL_MODE影响：开启STRICT_TRANS_TABLES时，字段类型隐式转换失败也会在预处理阶段报错，而非静默截断
无法跳过预处理器，但可以绕过部分检查
你不能禁用预处理器，也无法让它“忽略字段不存在”。但有些写法能避开它的校验路径：
比如动态SQL：在存储过程中用CONCAT拼接字符串再PREPARE执行，预处理器只检查PREPARE语句本身是否合法，不校验拼出来的SQL内容——但这只是把检查延后到真正执行时，错误类型变成1054或1146，不会消失。
-
SELECT * FROM (SELECT 1 AS a) t WHERE a = 1这类子查询，预处理器会展开后检查所有字段，不能靠别名混淆 - 使用
INFORMATION_SCHEMA本身做条件判断（如SELECT COUNT(*) FROM information_schema.columns WHERE ...）是安全的，因为这是查元数据，不是引用业务表 - 权限检查也在此阶段完成：即使表和字段都存在，若用户没有
SELECT权限，一样会卡在预处理，报Access denied
预处理器不声不响，但它是SQL能否真正跑起来的第一道硬门槛。很多“明明语法没错却报错”的问题，根源都在它查元数据这一步——而它查得有多细，取决于你有没有改过表、换过库、或者连太久没重连。
