MySQL解析器只校验词法和语法规则，不检查表或字段是否存在；它将SQL拆为token并按固定顺序（FROM→JOIN→WHERE→SELECT→ORDER BY等）验证结构合法性，语法错误报ERROR 1064，语义错误如表不存在则后续阶段才报错。
解析器只认词法和语法规则，不查表或字段是否存在
MySQL 解析器（Parser）在收到 SELECT 语句后，第一件事是做词法分析：把整条 SQL 拆成一个个 token，比如 SELECT、FROM、users、=、1。接着按固定语法规则检查这些 token 的排列顺序是否合法。
它**完全不访问元数据**——哪怕你写 SELECT * FROM nonexistent_table，只要语法结构没错，解析器就放行；但写成 SELEC * FROM users（少个 T），或者 SELECT * FROM users WHERE 后面直接跟分号，就会卡在这一步，报 ERROR 1064 (42000)。
-
SELECT必须有字段列表（哪怕写*），不能空着 -
WHERE后必须跟表达式，不能光留个关键字 - 字符串字面量必须成对闭合，
'hello少个单引号就失败 - 括号必须配对，
SELECT COUNT(*) FROM t WHERE id IN (1,2直接报错
语法校验顺序严格固定，错误位置可能“偏移”
MySQL 解析器不是逐字扫描，而是按标准 SQL 执行顺序校验：从 FROM 开始，然后是 JOIN、ON、WHERE、GROUP BY、HAVING、SELECT、DISTINCT、ORDER BY、LIMIT。这意味着：如果 ORDER BY 写在 GROUP BY 前面，错误会立刻抛出，哪怕前面的 FROM 和 WHERE 都没问题。
更麻烦的是，多行注释 /* 如果没闭合，会导致后续所有语句被吞掉，报错位置往往远偏离真实问题行。例如：
SELECT * FROM users /* 这里忘了写 */ WHERE id = 1;
解析器会把 WHERE 当作注释内容跳过，最终报错在下一条语句开头，而不是这行本身。
用 EXPLAIN 或 PREPARE 可提前触发语法校验
想在不真正执行的前提下验证语法，有两个轻量级办法：
- 运行
EXPLAIN SELECT ...：它必须先通过解析器，语法错就直接报ERROR 1064；语义错（如表不存在）则报ERROR 1146或ERROR 1054，说明已过了语法关 - 用
PREPARE stmt FROM '...'：只要字符串里语法不对，PREPARE就失败，且不生成任何执行上下文，适合脚本批量预检 - 命令行加
--force参数（mysql --force -e "SELECT ..."），能让客户端跳过单条语法错误继续执行下一条，方便批量筛查
注意：EXPLAIN 不校验权限或字段拼写——那些是预处理器干的事，不在解析器职责范围内。
大小写和空格影响解析结果
MySQL 解析器默认区分大小写（尤其在开启 lower_case_table_names=0 时），select * from Users 和 SELECT * FROM users 被视为两条不同语句，缓存、解析树都分开处理。空格虽不影响语法合法性，但会影响 token 切分边界：比如 SELECT*FROMt 会被拆成 SELECT*（一个 token），导致解析失败——必须有空格或换行分隔关键字与标识符。
实际调试时，别依赖“看起来像对的”，复制粘贴后建议手动加空格、统一大小写再试；生产环境脚本最好用 lower_case_table_names=1 避免大小写歧义，但要注意这不改变解析器本身的大小写敏感逻辑。
