ERROR 1064 错误应紧盯 near 'xxx' 后的非法 token，真正问题几乎总在其前方；行号不可靠，需用 grep 筛语句行、echo 动态 SQL、--force 模式或 sqlformat 格式化定位真实错误点。
直接看 ERROR 1064 提示里的 near 'xxx' —— 那不是错误原因，而是 MySQL 解析器“卡住”的第一个非法 token。真正的问题几乎总在它前面。
盯住 near 后面那个词，别信行号
near 'xxx' 是唯一可信线索，at line Y 基本不可靠：注释、空行、长字符串、多行注释都会让行号偏移。比如 near ')'，大概率是前面少了个 ( 或多了一个逗号；near 'order'，说明 order 被当成了关键字而非字段名；near ''（空字符串），往往是末尾多分号、或字符串里有未转义的单引号（如 O'Reilly 应写成 O\'Reilly 或 O''Reilly）。
不要手动数行。用这行命令筛出实际语句行：grep -n -E '^[^[:space:]#;]|;$' file.sql，再查第 Y 行附近上下文。
动态拼接 SQL 时先 echo 出来再检查
90% 的 near '' 类错误来自 shell 或 Python 动态拼接后变量为空。比如："SELECT * FROM $table WHERE id = $id AND status = 'active'"，若 $table 为空，实际执行的是 SELECT * FROM WHERE id = ...，解析器直接卡在空格后。
- shell 脚本里加
echo "$sql"再复制执行 - Python 里打印
cursor.mogrify("...", args)（pymysql）或query % args（旧式） - 确认所有标识符（表名、字段名）没被套进单引号或双引号里——MySQL 只认反引号
`或不加引号
用 --force 模式和 sqlformat 暴露结构断裂点
mysql --no-auto-rehash --force -e "source /dev/stdin" 管道执行，比普通客户端输出更细的中断位置；sqlformat（基于 sqlparse）能自动缩进换行，一眼看出括号不配对、子查询没闭合、WHERE 后缺条件等视觉断裂。
特别注意这些易漏点：
- CREATE TABLE 最后一个字段后多逗号：
id INT,→ 5.7 报错，8.0+ 允许 - 字符串里混入中文标点（全角逗号、顿号、引号），
near '，'就是线索 - 参数化查询中给占位符手动加引号：
"INSERT INTO t VALUES ('%s')"→ 实际变成VALUES ('"alice"')，触发near '"alice"'
保留字冲突必须查 INFORMATION_SCHEMA.KEYWORDS
升级 MySQL 后突然报错，near 'rank'、near 'json'、near 'interval' 这类词，优先执行：SELECT * FROM INFORMATION_SCHEMA.KEYWORDS WHERE WORD = 'rank' AND RESERVED = 1;
返回一行？必须加反引号。返回空？那不是保留字，问题在别处。注意：mydb.order 不报错，但单独写 order 就崩；修复顺序是：改名 > 加反引号 > 调 sql_mode。
最常被忽略的是字段名出现在点号后可豁免，但出现在 SELECT 列表、WHERE 条件、ORDER BY 中就必须统一加反引号——漏一个就全挂。
