mysql用户权限突然失效需依次排查：检查mysql.user表中用户是否存在、account_locked和password_expired状态；确认authentication_string是否为空或无效；验证host匹配逻辑，注意localhost与127.0.0.1区别；用select user(), current_user()比对认证身份；通过show grants确认实际权限层级与作用域；若无审计日志，需依赖备份或配置管理工具追溯变更。
MySQL用户权限突然失效，先查mysql.user表是否被意外刷新
权限不是“实时生效”的——很多操作（比如DROP USER、CREATE USER、FLUSH PRIVILEGES）会重载权限缓存，但也有不少情况是表数据本身被改了却没触发重载。最常见的是运维脚本或自动化工具直接UPDATE或DELETE了mysql.user表，而没执行FLUSH PRIVILEGES，导致内存缓存和磁盘数据不一致。
- 用
SELECT host, user, authentication_string, account_locked FROM mysql.user WHERE user = 'xxx';确认该用户记录是否还存在、account_locked是否为Y - 检查
password_expired字段，值为Y会导致登录成功但后续任何操作都报ERROR 1820 (HY000): You must reset your password using ALTER USER statement - 如果
authentication_string为空或为*（旧版空密码哈希），说明密码可能被清空，但FLUSH PRIVILEGES后仍会按空密码校验——这在新版本中默认被禁用
连接时提示Access denied for user但账号密码没错？重点看host匹配逻辑
MySQL权限是(user, host)二元组决定的，不是单看用户名。很多“权限突然失效”其实是客户端IP变了（比如从127.0.0.1切到localhost，或容器网络重启后分配了新IP），而权限只给了某个特定host值。
-
localhost和127.0.0.1在MySQL里是两个完全不同的host：前者走socket连接，后者走TCP，权限记录必须分别授权 - 检查
SELECT host, user FROM mysql.user;，确认当前连接来源的host是否在列表中；若用通配符如'%'，注意它不匹配localhost（这是MySQL硬编码规则） - 用
SELECT USER(), CURRENT_USER();对比：前者是客户端声明的身份，后者才是MySQL实际认证通过的(user@host)——如果两者不一致，说明匹配到了意料之外的账户行
执行SQL时报ERROR 1142: SELECT command denied？权限未生效或作用域错位
权限分层级（global / db / table / column），且高优先级层级会覆盖低优先级。突然报拒绝，大概率是某层权限被显式REVOKE，或GRANT时漏写了ON *.*之类的作用域。
- 用
SHOW GRANTS FOR 'user'@'host';查当前生效的全部权限语句，注意输出里是否真包含你需要的操作（比如SELECT）和对应库表（比如mydb.*） - 如果只授了
GRANT SELECT ON mydb.* TO ...，但代码连的是information_schema或执行了USE otherdb，就会立刻报错——权限不跨库自动继承 -
REVOKE ALL PRIVILEGES ON *.* FROM ...不会删用户，但会清空所有全局权限；若之前只靠全局权限干活，这就直接断掉
错误日志里找不到权限相关记录？MySQL默认不记授权类操作
MySQL的error log（由log_error配置）主要记启动失败、崩溃、连接异常等，GRANT/REVOKE/DROP USER这类操作默认不写入。想追溯谁动了权限，得提前打开通用查询日志或审计插件。
- 临时开启通用日志：
SET GLOBAL general_log = ON;，日志会记所有语句（含GRANT），但性能损耗大，仅限紧急排查 - 生产环境应部署
mysql_enterprise_audit插件或Percona Server的audit_log，它们能过滤出权限变更类事件 - 如果没有审计手段，就只能翻数据库备份或配置管理工具（Ansible/Terraform）的历史提交，看是否有
mysql_user模块执行记录
权限问题最麻烦的从来不是“怎么修”，而是“谁什么时候动的”。没留痕的环境，下次出问题还是得靠人肉对mysql.user和mysql.db快照做diff。
