ERROR 1064的“near 'xxx'”提示直接指向MySQL解析失败的关键位置，xxx多为保留字（如order、rank、json）、未引号标识符或非法字符；应优先查INFORMATION_SCHEMA.KEYWORDS确认是否RESERVED=1，再统一加反引号或改名。
看懂 ERROR 1064 near 后面那个词到底是什么意思
升级 MySQL（尤其是到 8.0+ 或 9.6）后，ERROR 1064 突然变多，大概率不是你写错了，而是某个字段名或表名撞上了新增的保留字。关键不是查整条 SQL，而是盯住 near 'xxx' 里的 xxx：
- 如果
near 'order'，说明解析器在ORDER BY之前就卡住了——order很可能被当成了关键字，而不是你的表名或列名 - 如果
near 'rank'、near 'json'、near 'group'，同理：这些在 MySQL 8.0+ 都是保留字，未加反引号就会直接报错 - 如果
near 'interval'，注意它和begin/end不同——INTERVAL是保留字，必须写成`interval`；而BEGIN和END只是非保留关键字，通常可不引 - 特别陷阱：
near ''（空字符串）往往意味着语句末尾多了一个分号，或字符串里有未转义的单引号（如'O'Reilly'应为'O''Reilly'），但升级后更常见的是字段名被截断识别失败
用 INFORMATION_SCHEMA.KEYWORDS 快速确认是不是保留字
别靠记忆或网上搜列表，MySQL 自己就带权威清单。执行这条语句，立刻验证：
SELECT * FROM INFORMATION_SCHEMA.KEYWORDS WHERE WORD = 'order' AND RESERVED = 1;
返回一行？就是保留字。返回空？那它只是普通关键字，一般不用引。这个表在 MySQL 8.0+ 和 9.6 中都存在，且实时反映当前版本规则。
-
RESERVED = 1表示必须加反引号才能作标识符（如表名、列名） -
RESERVED = 0表示非保留，但某些上下文（如存储过程标签）仍受限，日常用一般安全 - 注意：字段名出现在点号后时可豁免，比如
mydb.order不报错，但order单独出现就一定报
修复策略优先级：改名 > 加反引号 > 调 sql_mode
遇到保留字冲突，按以下顺序决策，别一上来就改配置：
-
首选改名：把
order改成order_info，group改成user_group。既避开问题，又提升语义清晰度，ORM 映射也更稳 -
次选加反引号：只在无法改名时用（如历史表、第三方库强制字段）。所有涉及处必须统一，包括
SELECT `order`、WHERE `order`.id = 1、JOIN `order` AS o—— 漏一个就崩 -
不推荐关 STRICT_TRANS_TABLES：有人想通过
SET sql_mode = 'NO_ENGINE_SUBSTITUTION'来绕过，但这不会让保留字变合法，只是掩盖语法错误，且会纵容其他隐式转换风险。MySQL 9.6 已明确将这类行为列为不兼容变更
ORM 场景下最容易漏的三个地方
用 Hibernate、MyBatis 或 Django ORM 时，保留字问题常藏得更深：
- MyBatis 的
<resultMap>里写<result column="rank" property="rank"/>—— 这里column值必须加反引号：column="`rank`" - Hibernate 实体类上用
@Column(name = "show")，而show是 MySQL 8.0+ 保留字 → 必须写成@Column(name = "`show`") - Django 的
models.CharField(db_column='order')同样要改成db_column='`order`'；否则 migrate 生成的 SQL 会直接失败
最易忽略的是 JOIN 别名和子查询别名：即使主表名加了反引号，FROM `order` AS o JOIN user ON o.user_id = user.id 里 o 是别名，没问题；但如果写成 FROM `order` JOIN user 少了 AS，部分驱动会把 JOIN 当作字段名解析，再次触发 near 'JOIN'。
