查当前用户权限用 SHOW GRANTS FOR 'username'@'host'; 命令，需写全用户名和主机名；若报错 ERROR 1141 则账号未创建；GRANT 后不生效常见于 host 不匹配、权限作用域错误或底层权限表被隐式拒绝。
查当前用户权限用什么命令
权限配置出问题，第一反应不是改配置，而是确认 MySQL 实际给了谁什么权限。用 SHOW GRANTS 最直接：
SHOW GRANTS FOR 'username'@'host';
注意必须写全 'username'@'host'，比如 'appuser'@'192.168.1.%' 和 'appuser'@'%' 是两个不同账号，权限不互通。如果提示 ERROR 1141 (42000): There is no such grant defined for user ...，说明该账号根本不存在——不是权限没生效，是压根没创建成功。
GRANT 后权限不生效的常见原因
执行了 GRANT 却连不上、报 Access denied，大概率卡在这几个点：
-
FLUSH PRIVILEGES不是必须的：MySQL 5.7+ 在大多数情况下自动重载权限表，手动执行反而可能掩盖问题；只有修改了mysql.user表直插数据后才需要它 - 客户端连接时用的 host 和授权时的 host 不匹配：比如授权用了
'user'@'localhost'，但应用连的是127.0.0.1，这两个在 MySQL 里被视为不同 host（localhost走 Unix socket，127.0.0.1走 TCP） - 权限作用域写错：比如对数据库授权写了
GRANT SELECT ON *.*，但实际只想给mydb.*，结果用户能查所有库，反而因安全策略被中间件拦截
权限继承与精确匹配规则
MySQL 权限检查是「从细到粗」逐层匹配，不是叠加生效。例如：
GRANT SELECT ON `orders`.* TO 'u1'@'%'; GRANT INSERT ON `orders`.`items` TO 'u1'@'%';
这时 u1 对 orders.items 有 SELECT（来自库级）和 INSERT（来自表级），但没有 UPDATE。如果再加一条：
可完全访问 Exchange 2010 EWS，管理邮件、文件夹、附件、日历事件、联系人、任务及外出设置。
REVOKE UPDATE ON `orders`.* FROM 'u1'@'%';
不会影响 items 表的 UPDATE 权限——因为表级授权未被撤销。反过来，如果只授了库级权限，又对某张表 REVOKE，那张表就真没权限了。权限不是布尔叠加，是按层级查最近的一条有效规则。
用 SELECT FROM mysql.tables_priv 排查隐式拒绝
当用户明确被授予了某权限，却仍报错，可能是被更细粒度的拒绝规则覆盖。MySQL 支持列级、表级 DENY（通过 mysql.columns_priv / mysql.tables_priv），这些不会出现在 SHOW GRANTS 里。查是否有人动过底层权限表：
SELECT * FROM mysql.tables_priv WHERE User='username' AND Host='host' AND Db='dbname' AND Table_name='tablename';
如果返回非空且 Table_priv 字段含 ''（空字符串）或显式 DROP 类权限缺失，说明该表权限被限制在比你预期更低的级别。这类配置极易被运维脚本误操作写入，且难以通过常规授权命令清理。
权限系统真正复杂的地方不在语法，而在 host 匹配顺序、权限层级覆盖、以及底层表被绕过 GRANT 直接修改的隐蔽状态——这些地方一不留神就变成线上故障的定时器。
