mysql 8.0升级后建表报error 1064，主因是使用了rank、json等新增保留字作列名，须用反引号包裹且所有引用处均需添加，set sql_mode='ansi_quotes'无法绕过该限制。
MySQL 8.0 升级后建表失败提示 ERROR 1064
这是最典型的信号：你用了 MySQL 8.0 新增的保留字当列名或表名，比如 rank、json、group、window、recursive。老版本不报错，8.0 语法解析更严格，直接拒掉。
别急着改代码，先确认是不是这个词真被占用了：
- 查官方保留字列表：MySQL 8.0 Reserved Words，重点看「Reserved」栏为 YES 的词
- 用
SELECT VERSION();确认确实是 8.0+（有些云服务默认开 8.0 兼容模式但实际内核还是 5.7） - 错误信息里会明确指出哪部分语法不对，比如
near 'rank INT' at line 1—— 那rank就是问题源
列名含保留字时要不要加反引号
要，而且必须加，只加一次、只在定义和引用处加，不是“保险起见多加几层”。不加就语法错误；加了就正常，但要注意范围：
-
CREATE TABLE t1 (id INT, `rank` INT);—— 建表时列名必须用`rank` -
SELECT id, `rank` FROM t1;—— 查询时也得用`rank`，不能漏 -
ALTER TABLE t1 CHANGE `rank` `score` INT;—— 改名时旧名新名都得包，否则报错 - 别在应用层拼 SQL 时漏掉反引号，ORM 如 SQLAlchemy 默认不自动加，Django 的
db_column也不自动转义
用 SET sql_mode = 'ANSI_QUOTES' 能绕过吗
不能。这个模式只是让双引号支持标识符（类似 PostgreSQL），但它不解除保留字限制，反而可能让问题更隐蔽：
-
SET sql_mode = 'ANSI_QUOTES'; SELECT "rank" FROM t1;—— 这条能跑，但只是因为双引号此时被当标识符用，不是因为rank不再是保留字 - 一旦换回默认模式，或者别人没设这个 mode，SQL 立刻失效
- 它不影响 DDL（如
CREATE），建表时仍需反引号，"rank"在建表语句里不合法 - 团队协作中统一 mode 成本高，还容易和字符集、严格模式等冲突
升级前怎么低成本发现潜在冲突
别靠人肉扫代码。MySQL 自带工具就能筛：
- 导出现有表结构：
mysqldump -d -u user db_name > schema.sql（-d只导结构） - 用正则快速定位风险词：
grep -E '`(rank|json|window|group|recursive|role|system)`' schema.sql，注意反引号是关键词边界 - 检查慢查询日志或业务 SQL 日志，过滤出含这些词的
SELECT/UPDATE，确认是否已被反引号包裹 - 如果用的是 Flyway/Liquibase，检查
V*__*.sql文件里有没有裸写保留字
真正麻烦的不是建表，是那些藏在存储过程、触发器、视图定义里的裸名 —— 它们不会在 SHOW CREATE TABLE 里暴露，得单独抽出来验。
