1064 错误本质是 MySQL 拒绝执行当前 SQL 语句
它不是运行时逻辑错误，而是解析阶段就失败了——MySQL 在“读你写的 SQL”时卡住了，根本没走到执行那步。错误信息末尾的
You have an error in your SQL syntax; check the manual...已经说得很直白：它不认你这句 SQL 的写法。
最常踩的三个坑：保留字、动态表名/字段名、参数占位符滥用
这三个场景加起来覆盖了 80% 以上的 1064 报错，而且它们长得都很像“语法没错”，实则暗藏陷阱：
用到了 MySQL 保留字当标识符：比如字段叫match、
order、
group、
resume，不加反引号就直接报错。正确写法是
`match`、
`order`； 用 Python 拼接表名或字段名时误用 %s 占位符：像
cursor.execute("INSERT INTO %s VALUES (%s)", (table_name, value)) 是错的——%s只能用于**值**，不能用于表名/字段名；MySQL 会把
'users'当成字符串字面量，生成类似
INSERT INTO 'users' ...的非法语句；必须用 Python 字符串格式化（如 f-string）拼接标识符，值再交给
%s绑定； MySQL 版本升级导致语法过时：比如 MySQL 5.7+ 废弃了
PASSWORD()函数，
SET PASSWORD = PASSWORD('xxx') 会直接触发 1064；应改用 ALTER USER 'root'@'localhost' IDENTIFIED BY 'xxx';。
快速定位问题的实操方法
别靠猜。直接看错误提示里最关键的一段：
near 'xxx' at line N——它告诉你 MySQL 解析到哪卡住了，“xxx” 就是它最后成功读到的内容，出错点就在它后面。 复制整条 SQL，粘贴进
mysql命令行或 phpMyAdmin 手动执行，看是否复现（排除程序层转义干扰）； 逐段删减：先删 WHERE，再删 ORDER BY，再删字段列表，直到不报错，就能锁定问题模块； 检查引号嵌套：Python 中用双引号写 SQL，里面字段值却混用双引号（
"INSERT INTO t VALUES ("abc")"），会导致字符串提前截断，生成残缺 SQL；
确认客户端连接的 MySQL 版本：SELECT VERSION();，不同版本对窗口函数、CTE、JSON 函数等支持差异很大。
Python + PyMySQL 场景下的典型修复示例
这是最容易栽跟头的地方，尤其在动态建表、批量插入时：
❌ 错误写法（表名用 %s）：
cursor.execute("INSERT INTO %s (id, name) VALUES (%s, %s)", ("users", 1, "Alice"))
→ 报错：
You have an error in your SQL syntax near ''users' (id, name) VALUES (1, 'Alice')'
✅ 正确写法（标识符用 f-string，值用 %s）：
table = "users"
cursor.execute(f"INSERT INTO `{table}` (id, name) VALUES (%s, %s)", (1, "Alice"))
注意两点：一是表名用
f-string拼进去，二是加上反引号
`防保留字冲突；值仍走安全绑定。
真正麻烦的从来不是语法本身，而是你以为它“应该能跑通”的那部分——比如字段名看着不像关键字，但其实 MySQL 8.0 新增了
role、
admin等保留字；又比如本地开发用 MySQL 5.6，上线却是 8.0，
GROUP BY严格模式直接让旧 SQL 失效。多看
near后面那一小段，比查文档快十倍。
