MySQL授权时碰到1064错误，排错时先别急着怀疑语法，多数情况下是三个“隐形杀手”在捣乱。我们来逐个拆解，看完就能精准定位。

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语句在不同终端表现不一致。排查时记得用十六进制查看器扫一遍，别光靠眼睛。