先确认实际认证用户：执行select user(), current_user();，前者是客户端声明身份，后者才是mysql真正匹配并鉴权的账号；若不一致，说明host匹配导致权限降级，须用show grants for current_user();查真实生效权限。
直接看 CURRENT_USER() 返回的账号，再查它的真实权限——90% 的“权限不足”不是没授权，而是你连的根本不是你以为的那个用户。
先确认你实际登录的是谁
执行 SELECT USER(), CURRENT_USER();。前者是客户端声明的身份（可能带错 IP），后者才是 MySQL 真正匹配并认证成功的账号。如果两者不一致，说明存在多个同名用户（比如 'app'@'localhost' 和 'app'@'127.0.0.1'），MySQL 按 host 匹配规则选中了权限更小的那个。
常见陷阱：
- 你在命令行用
mysql -u app -p -h 127.0.0.1连，但只创建了'app'@'localhost'——这两个 host 不等价，Linux 下localhost默认走 socket，127.0.0.1走 TCP -
Host字段区分大小写，'app'@'%'和'app'@'%'（末尾空格）是不同记录 - 有匿名用户
''@'localhost'存在时，它会优先匹配无用户名的连接，导致权限意外降级
查权限别只看 GRANT 语句，要看 SHOW GRANTS FOR CURRENT_USER()
不要凭记忆或建库脚本判断权限，执行 SHOW GRANTS FOR CURRENT_USER(); 才反映当前 session 真实生效的权限集合。注意：
- 权限按层级合并：全局 > 数据库 > 表 > 列；但表级显式拒绝（
DENY）会覆盖更高层授权（MySQL 8.0+ 支持） - 如果报错涉及
mysql.user表，得单独查：SHOW GRANTS FOR CURRENT_USER() ON mysql.user;（MySQL 8.0.16+ 支持） -
USAGE权限 ≠ 可操作，它只是允许登录，不附带任何数据库操作能力
检查 mysql.user 表本身有没有被绕过或写错
手动改 mysql.user 表（如 UPDATE Select_priv='Y'）极不可靠——MySQL 不保证运行时读取这些字段，且重启后可能被覆盖。正确做法是只用 GRANT / CREATE USER 语句管理权限。
排查点：
- 执行
SELECT Host, User, plugin, account_locked FROM mysql.user WHERE User = 'your_user';，确认plugin是caching_sha2_password（8.0 默认）还是mysql_native_password，客户端不兼容会导致看似“登录成功但权限异常” -
account_locked = 'Y'会直接禁用账号，哪怕密码正确、权限齐全 - MySQL 8.0+ 引入角色（role），若用户权限来自角色，需确认角色已激活：
SELECT * FROM INFORMATION_SCHEMA.APPLICABLE_ROLES;，或检查activate_all_roles_on_login配置
GRANT 后权限不生效？别只盯 FLUSH PRIVILEGES
FLUSH PRIVILEGES; 在用 GRANT 授权后通常非必需（5.7+ 多数情况自动刷新），但它能解决某些配置下的延迟问题。真正卡住权限生效的，往往是：
- 连接复用：应用用了连接池，旧连接仍持有旧权限缓存，需重启连接池或等待连接重建
- host 匹配失败：授的是
'user'@'192.168.1.%'，但连接来源是192.168.100.5，通配符未覆盖 - SQL 模式干扰：比如
sql_mode=STRICT_TRANS_TABLES导致 INSERT 因字段缺失被拒，错误信息像权限问题，实为约束拦截
最易被忽略的是：权限必须作用于你正在操作的**具体对象层级**。例如导入 SQL 时指定数据库 mydb，但只授了 GRANT ALL ON *.*，MySQL 会拒绝 CREATE TABLE——因为 DDL 权限需显式授予目标库：GRANT CREATE, DROP ON `mydb`.* TO 'user'@'host';。
