error 1142是登录成功后执行命令被拒，需精准匹配操作类型、数据库层级及连接来源授权；error 1045则是登录阶段认证失败，因user@host元组不匹配、密码错误或插件不兼容。
报错“Access denied”或“command denied”不是账号密码错了，而是当前用户没被授予对应操作所需的最小权限集——必须按操作类型、数据库层级、连接来源三者精准匹配授权。
怎么判断是登录失败还是权限不足
ERROR 1045 是登录阶段失败，说明用户名、密码、Host三者没对上；ERROR 1142 才是登录成功后执行具体命令（如CREATE、INSERT）被拒。登录后立刻执行 SELECT USER(), CURRENT_USER();：前者显示你“声称是谁”，后者显示MySQL“认你是谁”。如果两者不同，比如 USER() 返回 'app'@'192.168.1.100' 而 CURRENT_USER() 返回 'app'@'%'，说明有多个同名用户，MySQL选中了权限更小的那个。
导入SQL脚本时卡在CREATE TABLE怎么办
常见现象是 mysql -u user -p mydb 执行到第一条 <code>CREATE TABLE 就报 CREATE command denied。这不是没给权限，而是权限没给到 mydb 这个库层级。
- 必须显式授库级权限：
GRANT CREATE, DROP, INSERT ON `mydb`.* TO 'user'@'host';（注意反引号包裹库名） - 不能只靠
GRANT ALL ON *.*—— MySQL 在指定了目标库的导入场景下，会跳过全局权限检查，直接查该库的显式授权 - 授完权别忘了
FLUSH PRIVILEGES;，尤其在旧版本或某些配置下，否则不生效 - 如果SQL文件开头有
CREATE DATABASE，还需额外加GRANT CREATE ON *.*
为什么授了FILE或SUPER反而解决不了问题
FILE 权限只用于 LOAD DATA INFILE 或 SELECT ... INTO OUTFILE，和 mysql -u -p db 完全无关；<code>SUPER 在标准导入中几乎不会触发，除非SQL里硬写了 SET GLOBAL 或用了 --set-gtid-purged=ON 导出的dump。云数据库（如阿里云RDS）默认禁用 SUPER，且MySQL 8.0.30+已将其标记为 deprecated。盲目授权不仅无效，还违反最小权限原则。
容易被忽略的非权限因素
有些报错看着像权限问题，实际是其他配置拦截：
-
secure_file_priv限制了文件读取路径，但只影响LOAD DATA，不影响普通SQL导入 - SQL模式启用
STRICT_TRANS_TABLES，导致插入违规数据被拒绝，错误码仍是1142，但本质是数据校验失败 - 存储过程/函数里定义了
DEFINER = 'root'@'localhost'，而当前用户没有root的权限，执行时就会报权限错 - Navicat等GUI工具连接后自动执行
SHOW PROCESSLIST，需要PROCESS权限——这个操作和导入SQL完全无关，但错误码也是1227
真正关键的是：先看报错上下文——是刚连上就弹窗，还是执行某条语句时崩？前者查连接参数和Host匹配，后者才查权限；再确认SQL里有没有隐含高危语句（如SET GLOBAL、RESET MASTER），它们才是真正触发1227的元凶。
