MySQL 1064错误根源90%藏于报错末尾“near 'xxx'”处：xxx多为保留字（如order、user）、未引号字符串、版本不兼容语法或未转义特殊字符，须加反引号、补单引号、查版本手册或转义处理。
直接看错误提示末尾的 near 'xxx' 部分，90% 的 1064 错误根源就藏在那里——不是语句整体写错，而是某个词被 MySQL 当成了语法结构，实际却是字段名、表名或用了旧版不支持的写法。
查 near 后面的内容，先定位冲突关键字
MySQL 报错时一定会告诉你卡在哪：“ERROR 1064 (42000): ... near 'order' at line 1” 或 “near 'user' at line 3”。这个 order、user 很大概率就是 MySQL 保留字。
- 别急着改逻辑，先去官网查 MySQL 8.0 关键字列表（或你实际用的版本），确认它是不是保留字
- 如果是，所有出现位置都得加反引号：
`order`、`user`，不能只在 CREATE TABLE 里加，SELECT、UPDATE、WHERE 里也得加 - 常见踩坑点：
group、key、desc、range、interval这些看着像普通词的，全是保留字；password在 5.7+ 已弃用，authentication_string才是字段名，但直接写password('xxx')函数也会触发 1064
检查 SET PASSWORD 和 GRANT 语句的版本兼容性
这类操作报 1064，基本不是你手抖，而是语法被版本砍掉了。比如：
- MySQL 5.7+ 不再支持
SET PASSWORD = PASSWORD('xxx')，必须写成SET PASSWORD = 'xxx'（明文）或走ALTER USER -
GRANT ... IDENTIFIED BY在 5.7.6+ 被移除，再用就报错；应拆成CREATE USER+GRANT两步 - 低版本写的
LIMIT 10 OFFSET 5在 MySQL 5.5 及以前不认，得改成LIMIT 5,10 - 执行前先查版本：
SELECT VERSION();，再翻对应版本的手册，别凭记忆写
字符串值和日期值漏引号是最隐蔽的“语法错误”
看起来是数据问题，但 MySQL 解析器会把它当成语法错误抛 1064，因为没引号就无法识别字面量边界。
- 字符串值必须用单引号：
INSERT INTO t(name) VALUES('张三');，写成VALUES(张三)就报错 - 日期也必须加单引号且格式规范：
'2024-03-13'或'2024-03-13 10:20:30'，写成2024-03-13（无引号）会被当减法运算，直接语法崩 - 插入含单引号的文本，如
O'Reilly，必须转义：'O\'Reilly'或用双单引号：'O''Reilly' - 用 Python、PHP 拼 SQL 时，尤其注意变量插进去后是否带了引号——
"WHERE name = '" + name + "'"比预编译更易漏
触发器、存储过程里换行和分号容易引发解析错乱
这类对象定义本身是多行 SQL，但 MySQL 客户端默认以分号为语句结束符，导致中间的 ; 被提前截断。
- 建触发器前必须改 delimiter：
DELIMITER $$，然后把触发器体内的分号换成$$，最后再DELIMITER ; - 少一个
DELIMITER切换，或者END$$写成END;，就会报near 'END;'类错误 - 函数体里如果用了游标或异常处理，
DECLARE必须放在所有语句最前面，顺序错也会被当语法错 - 用 MySQL Workbench 或 DBeaver 等 GUI 工具时，它们会自动处理 delimiter，但命令行 mysql 客户端不会
真正难排查的 1064，往往不是语法写错，而是你以为它是个名字，MySQL 认为它是关键字；你以为它是个值，MySQL 认为它是未闭合的字符串；你以为它在当前版本能跑，其实那句语法早被标记为废弃。每次遇到，盯住 near 后那一小段，查文档、加反引号、核对版本，比重写整条语句快得多。
