Access denied错误需先查mysql.user表确认用户Host是否匹配连接地址，再检查skip-name-resolve、密码插件兼容性、权限刷新及元数据锁等深层原因。
MySQL报错“Access denied for user”怎么快速定位
这不是密码错了就重试的问题，得先确认是哪一层拦住了你。Access denied 错误实际由 MySQL 服务端在认证阶段抛出，但原因可能在用户账号、主机匹配、密码加密方式或代理层。最常被忽略的是 host 字段的精确匹配——比如你用 localhost 连，但账号只授权给了 127.0.0.1，或反过来，它们在 MySQL 权限系统里是两个完全不同的 host。
- 执行
SELECT User, Host FROM mysql.user WHERE User = 'your_user';
看该用户是否真的存在，且Host值和你连接时用的地址一致（localhost≠127.0.0.1） - 检查是否启用了
skip-name-resolve：如果开了，MySQL 不做 DNS 反查，Host必须写 IP 或%，不能依赖域名 - 如果是 MySQL 8.0+，确认用户用的是
caching_sha2_password插件，老客户端（如某些 Python 2.x 驱动、旧版 Navicat）不支持，会静默失败
GRANT之后还是没权限？别忘了FLUSH PRIVILEGES
直接改 mysql.user 表或用 INSERT/UPDATE 手动加权限，MySQL 不会自动加载——必须显式刷新。而用 GRANT 语句通常会自动生效，但有个例外：如果你在 GRANT 后又手动改过权限表，或者用的是 MySQL 5.7 之前的版本，GRANT 本身也可能不触发即时加载。
- 执行
FLUSH PRIVILEGES;
是最稳妥的兜底操作，尤其在调试阶段 - 注意：该命令只重载权限缓存，不重启服务，不影响已有连接，但新连接会立即生效
- 如果仍无效，检查是否对错误的数据库/表执行了
GRANT，例如：GRANT SELECT ON db1.* TO 'u'@'%'对db2.table没用
ERROR 1419：CREATE FUNCTION 被拒绝，其实是SUPER权限缺失
这个错误表面看是函数创建失败，实际是 MySQL 安全机制拦截：当函数包含 SQL 数据修改、或定义为 DETERMINISTIC 但未声明，MySQL 要求调用者拥有 SUPER 权限（MySQL 5.7 及以前）或 SET_USER_ID（MySQL 8.0+）。这不是普通 CREATE ROUTINE 权限能解决的。
- 临时方案（仅开发环境）：
SET GLOBAL log_bin_trust_function_creators = 1;
，绕过检查（但会关闭二进制日志对函数的校验） - 生产环境应明确授权：
GRANT SUPER ON *.* TO 'user'@'host';
（5.7）或GRANT SET_USER_ID ON *.* TO 'user'@'host';
（8.0） - 更安全的做法是避免用
DETERMINISTIC声明不可信函数，或改用存储过程 + 显式权限控制
无法DROP DATABASE：不是权限不够，而是有活跃连接锁着
即使你有 DROP 权限，DROP DATABASE 仍可能卡住或报错，因为 MySQL 在删除前会尝试获取库级排他锁。如果有长事务、未提交的 DML、或其它连接正在查这个库的表，就会阻塞。
- 先查谁占着：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE DB = 'target_db';
- 强制断开（谨慎）：
KILL
（ID 来自上一步查询结果）connection_id; - 若仍有元数据锁（MDL），可查
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'target_db';
，再结合PROCESSLIST定位源头
权限异常背后，往往是权限粒度、host 匹配逻辑、插件兼容性或元数据锁这些非直观因素在起作用。越想“快点修好”，越容易跳过 SELECT User, Host FROM mysql.user 这种基础验证。
