error 1064 中 near 'xxx' 的词大概率是 mysql 新版本的保留字，需查 information_schema.keywords 确认 reserved=1；若是则必须加反引号或改名，优先改名以避免 orm 和动态 sql 风险。
直接看 ERROR 1064 报错里 near 'xxx' 的那个词——它大概率就是 MySQL 新版本认作保留字的字段名或表名，不是你写错了，是它变严格了。
查确认是不是保留字：别猜，用 INFORMATION_SCHEMA.KEYWORDS
靠记忆或搜第三方列表容易漏，MySQL 自己就带权威清单。执行：
SELECT WORD FROM INFORMATION_SCHEMA.KEYWORDS WHERE WORD = 'order' AND RESERVED = 1;
返回一行？必须加反引号或改名。返回空？说明只是普通关键字，日常可不引。
-
RESERVED = 1表示该词在任何上下文都必须加反引号才能当标识符（如`order`） -
RESERVED = 0表示非保留，但某些场景（比如存储过程标签）仍受限，一般够用 - 注意：像
mydb.order这种带库名前缀的写法通常不报错，但单独写order就崩
修复优先级：改名 > 加反引号 > 调 sql_mode
别一上来就改配置，先评估改动成本和长期维护性。
- 首选改名：把
order改成order_info，group改成user_group——语义更清、ORM 映射稳、后续升级少踩坑 - 次选加反引号：只在无法改名时用（比如第三方 SaaS 表结构锁定），但所有地方必须统一：
SELECT `rank`、JOIN `json` AS j、WHERE `interval` > 0，漏一个就报错 -
SET sql_mode = 'ANSI_QUOTES'没用：它只让双引号能当标识符，不影响保留字限制；DDL 里写"rank"依然非法
特别容易漏的坑：动态 SQL 和 ORM 拼接
Java 或 Python 里用字符串拼表名/字段名，最容易翻车。
- 比如 Java 里
String.format("SELECT %s FROM t", field)，若field是"rank"，得提前处理成"`rank`" - MyBatis 的
${}是字符串替换，不防注入也不自动转义，遇到保留字必炸；优先用#{}参数占位，实在要拼也要手动加反引号 - Python 的 f-string 或
.format()同理，别信“我传进去的是变量”，运行时还是裸词解析
near ''（空字符串）这种报错怎么定位？
不是语法错得离谱，往往是字段名被截断识别失败，或末尾多了一个分号。
- 检查 SQL 末尾有没有多余分号，尤其批量执行时粘连了
- 查字符串里有没有未转义单引号，比如
'O'Reilly'应写成'O''Reilly'（两个单引号） - 更隐蔽的情况：字段名太长（超 64 字符），MySQL 8.0+ 截断后剩下半个词，解析器卡在
near ''
真正麻烦的不是单个 order 或 rank，而是它们藏在视图定义、触发器、函数体里——这些对象不会出现在 SHOW CREATE TABLE 中，却会在升级后首次调用时突然崩掉。
