如何修复MySQL中因非法字符导致的授权语句解析失败？

MySQL授权报1064错误主因有三：一是中文全角分号需换为英文半角；二是字段名如order、role等保留字须加反引号；三是密码含特殊字符时应避免shell传参，改用mysql_config_editor或单引号明文写入。

MySQL授权语句报1064且near后是中文分号

直接删掉语句末尾或中间的中文全角分号；，替换成英文半角分号;。MySQL只认ASCII范围内的标点，中文分号在十六进制里是E38082，解析器一读就崩，连关键字检查都跳过，直接报语法错误。

常见发生场景：

• 从微信、钉钉、Notion等富文本工具复制SQL，自动转成了全角符号
• Windows记事本保存为UTF-8 with BOM后，某些编辑器会把结尾分号渲染成中文样式
• 用Mac的“智能引号”功能写SQL，顺带把分号也“智能”了

验证方法：把整条语句粘进hexdump -C或在线十六进制查看器，搜e3 80 82（UTF-8中文分号）或ff 1b（全角ASCII映射区），有就是它。

GRANT语句里字段名触发保留字冲突

看到ERROR 1064 near 'order'或near 'role'，不是密码或权限问题，是MySQL 8.0+把order、role、group列为RESERVED = 1的保留字，未加反引号就当语法关键词处理了。

修复动作要快准狠：

• 立刻执行SELECT * FROM INFORMATION_SCHEMA.KEYWORDS WHERE WORD = 'order' AND RESERVED = 1;确认是否真被锁死
• 把出问题的标识符包上反引号，例如GRANT SELECT ON `mydb`.`order` TO 'u'@'%';
• 别改sql_mode去绕开——那等于给所有SQL埋雷，不是解法

注意：mydb.order不报错，但order单独出现必炸；大小写完全无效，Order和ORDER一样触发。

密码含特殊字符导致GRANT语句被shell截断

写GRANT ... IDENTIFIED BY 'pa@ss/wd:123';本身合法，但如果你是从命令行mysql客户端里粘贴进去的，而这个客户端启动时用了带特殊字符的密码参数（比如mysql -u root -p'pa@ss/wd:123'），shell早就在传参阶段把@和:当协议/路径分隔符切掉了，MySQL进程根本没收到完整密码字符串，后续解析直接失序。

安全做法只有两个：

• 在SQL里用单引号包密码，且不转义：CREATE USER 'u'@'%' IDENTIFIED BY 'pa@ss/wd:123';（MySQL自己能吃下）
• 彻底避开命令行传参：用mysql_config_editor set --login-path=local --user=root --password存密，再用mysql --login-path=local连，密码全程不经过shell

配置文件里严禁写password = pa@ss/wd:123——ini解析器同样会按等号和冒号拆段，结果比shell还脆。

动态拼接GRANT语句时混入不可见非法字符

Python或PHP脚本里用f-string或str.format()拼GRANT ... ON {db}.{table} TO ...，如果db或table变量来自用户输入或配置文件，极可能带BOM、零宽空格（U+200B）、软连字符（U+00AD）等肉眼不可见字符。MySQL解析到这种位置，直接中断词法分析，报错指向near ''（空字符串）。

防御性处理必须做两层：

• 拼之前先清洗：table_name.strip().replace('u200b', '').replace('ufeff', '')
• 拼完强制用反引号包裹：f"GRANT SELECT ON `{db}`.`{table}` TO ..."，既防保留字又防非法字符溢出

真正难缠的是那些在编辑器里显示正常、hexdump里才露馅的Unicode控制字符——它们不会出现在SHOW CREATE USER结果里，但会让同一条GRANT语句在不同终端表现不一致。