1064错误是MySQL在词法或语法分析阶段失败导致的解析错误，Explain对其无效；关键线索是报错信息中near后的字符位置，需检查拼写、引号、反引号、ASCII符号及参数化占位符使用是否规范。
1064错误不是执行慢或结果不对，而是SQL根本没被MySQL解析器接受——Explain对它完全无效，先别急着用。
为什么Explain查不了1064错误
Explain只作用于能通过语法校验的SQL语句。一旦出现ERROR 1064 (42000)，说明MySQL在“词法分析”或“语法分析”阶段就中断了，连生成执行计划的机会都没有。
- 你执行
EXPLAIN SELECT * FROM users WHERE name = 'alice';没问题，但EXPLAIN SELECT * FORM users;会直接报1064，不会进Explain流程 - Explain输出的是
id、type、key等字段，这些只有语法合法后才可能生成 - 试图对带拼写错误、引号错位、反引号滥用的SQL跑Explain，只会得到“语法错误”本身，没有任何额外结构信息
真正该看的错误提示位置
MySQL 1064报错信息里那句near 'xxx' at line N才是关键线索，它指向解析器卡住的**确切字符位置**，不是你写的第N行，而是它尝试解析时失败的那个token。
- 比如报错
near 'form employmoni' at line 1，说明它把form当成了非法关键字——你立刻知道是FROM拼错了 - 报错
near ''lrs_audit_rule_package'' at line 1，单引号包裹表名，而MySQL要求标识符用`（反引号）或不用引号；单引号会被识别为字符串字面量，导致语法断裂 - 复制粘贴来的SQL常含中文标点（如全角逗号、顿号、引号），MySQL只认ASCII符号，这类错误
near '，'会直接暴露
参数化查询中%s加引号是典型陷阱
用pymysql或mysql-connector-python时，如果在SQL模板里给占位符手动加引号，比如"INSERT INTO t (name) VALUES ('%s')"，就会触发1064。
- 正确写法是
"INSERT INTO t (name) VALUES (%s)"（不加引号），让驱动自动处理转义和类型适配 - 错误写法会让最终SQL变成
INSERT INTO t (name) VALUES ('"alice"')——多了一层引号，字符串值被当成带引号的字面量，破坏语法结构 - 这个错误在日志里表现为
near '"alice"')' at line 1，但根源不在SQL本身，而在Python字符串拼接逻辑
建表语句里最容易漏掉的三个点
CREATE TABLE出1064，90%集中在标识符、数据类型、注释三处混用符号。
- 表名/字段名用了单引号
'user_id'或双引号"user_id"：必须改用反引号`user_id`，或干脆不加（除非是保留字） - 写了
startDate data not null：MySQL没有data类型，正确是date，拼错或复制错一个字母就挂 - COMMENT后面跟了反引号：
COMMENT '`active`'是错的，COMMENT值是普通字符串，用单引号即可：COMMENT 'active'
1064本质是“MySQL没看懂你在写什么”，不是“它看懂了但执行得不好”。所有排查动作都要围绕“让它能读下去”展开——删掉可疑符号、还原ASCII字符、拆开长SQL逐段试、确认驱动是否接管了参数。Explain是给能跑通的SQL用的，别让它成为排查1064的第一反应。
