MySQL 8.0中SELECT * FROM rank报错1064，因rank是保留关键字，解析器在词法分析阶段将其识别为关键字而非表名，未加反引号则直接拒绝解析并抛出语法错误。
MySQL解析器不会对保留关键字做容错处理——它只做语法校验，不负责语义纠错。 遇到保留字被误用（比如当列名、表名），是否报错、何时报错，取决于你有没有用反引号`包裹，以及这个保留字出现在哪个阶段。
为什么SELECT * FROM rank在MySQL 8.0会报错1064？
因为rank是MySQL 8.0的保留关键字，解析器在词法分析阶段就把它识别为关键字而非标识符。一旦它出现在本该是表名的位置（比如FROM rank），解析器直接拒绝生成AST，抛出ERROR 1064 (42000)：“You have an error in your SQL syntax”。这不是预处理器或权限检查的问题，是纯语法层面的拦截。
常见触发场景包括：
- 建表时用
rank作列名但没加反引号：CREATE TABLE t (rank INT)→ 解析失败 - 查询中写
SELECT rank FROM t（无别名、无函数调用上下文）→ 解析器认为你在尝试用关键字当字段名，非法 - 复制环境中源库MySQL 5.7有
rank列，副本MySQL 8.0解析binlog事件时同样卡在解析阶段，哪怕该表已被--replicate-ignore-table过滤
`rank`加反引号后，解析器到底做了什么？
反引号强制将rank标记为“引用标识符（quoted identifier）”，绕过关键字词法识别流程。解析器此时不再把它当作RANK()窗口函数关键字或保留字，而是当成普通标识符处理，顺利进入后续阶段。
但注意：这只是语法放行，不代表万事大吉。例如：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 如果
`rank`指向一个不存在的列，错误会推迟到预处理器阶段才暴露 - 如果
SELECT RANK() OVER (...) AS `rank`，这里第一个RANK是函数名（未加引号），第二个`rank`是别名（加了引号），解析器能区分——函数名走关键字路径，别名走标识符路径
预处理器阶段还会检查保留字吗？
不会。预处理器只处理对象存在性、别名绑定、视图展开、临时表依赖等语义检查，它假设输入SQL已经通过了解析器校验。也就是说，只要解析器放行了（比如用了`rank`），预处理器就默认这是合法标识符，转头去查数据字典里有没有这张表、这个字段。
典型反例：
-
SELECT * FROM `non_existent_table`：解析器通过（反引号合法），预处理器查字典失败 → 报ERROR 1146 (42S02) -
SELCT * FROM users（SELCT拼错）：解析器直接拒识 →ERROR 1064，根本进不了预处理
真正容易被忽略的是：**保留字冲突不是运行时问题，而是解析时硬性拦截；加反引号不是“兼容开关”，而是告诉解析器“请按标识符规则处理我”——这一步漏掉，后面所有优化、权限、执行都无从谈起。**
