mysql如何查看权限表底部结构_mysql user/db/tables_priv解析

应直接用 show grants for ‘user’@’host’ 查真实权限，而非 select * from mysql.user；关键字段为 host、user、plugin 及 select_priv 至 grant_priv 等 y/n 权限位，mysql 8.0 起 authentication_string 替代 password，且 account_locked、password_expired 参与认证。

mysql.user 表结构怎么看才不踩坑

直接查 DESCRIBE mysql.user 会看到一堆字段，但真正影响登录和全局权限的只有几个关键列，而且 MySQL 8.0 和 5.7 字段差异很大——比如 plugin、account_locked、password_expired 在 8.0 才强制参与认证流程。

常见错误是用 SELECT * FROM mysql.user 看权限，结果被密文 authentication_string 和一堆 NULL 值搞晕；其实应该聚焦在：Host、User、Select_priv 到 Grant_priv 这组 Y/N 字段，以及 plugin 是否为 mysql_native_password（尤其连老客户端时）。

• MySQL 5.7 默认用 password 字段存哈希，8.0 起只认 authentication_string，改密码必须用 ALTER USER，直接 UPDATE 表无效
• Host 匹配是严格字符串比较，'%' 不匹配 localhost（unix socket 登录走的是 'localhost'，不是 '127.0.0.1'）
• Super_priv 关闭后，连 SHOW PROCESSLIST 都会被拒绝，别只盯着 DML 权限

mysql.db 和 mysql.tables_priv 的权限叠加逻辑

这两张表不是“或”关系，而是按粒度逐级覆盖：用户连接进来后，先查 mysql.user 得到全局权限，再按 db 和 table_name 查 mysql.db 和 mysql.tables_priv，最终权限是“所有匹配行的权限位 OR 合并”。容易出错的是 Db 字段大小写敏感（取决于 lower_case_table_names 设置），且 mysql.db 中 Host 和 User 必须同时匹配当前连接值。

• mysql.db 控制库级操作（如 CREATE TABLE、DROP database），但不控制 SELECT —— 那得看 tables_priv 或列权限
• mysql.tables_priv 的 Table_name 是精确匹配，不支持通配符；想限制某张表，必须显式 INSERT 一行，不能靠 %
• 如果 mysql.db 里某库设了 Select_priv='N'，但 mysql.tables_priv 又给其中一张表开了 'Y'，那这张表仍可查——因为更细粒度的权限优先

查权限别只用 SELECT，用 SHOW GRANTS 更可靠

SELECT 直接读系统表看似直观，但权限实际生效依赖多层缓存和运行时判断。比如刚用 GRANT 加的权限，可能还没刷进内存；或者 FLUSH PRIVILEGES 没执行，表数据已改但服务没 reload。

• 查某个用户真实生效权限，用 SHOW GRANTS FOR 'user'@'host'，它走的是运行时权限树，不是快照
• SHOW GRANTS FOR CURRENT_USER() 能暴露你当前连接实际拿到哪些权限，比猜 mysql.user 字段靠谱得多
• 如果 SHOW GRANTS 输出里没看到预期权限，八成是 GRANT 语句没带 WITH GRANT OPTION，或者目标用户根本不存在（MySQL 不报错，静默忽略）

mysql.columns_priv 和 performance_schema 的干扰项

mysql.columns_priv 确实存在，但极少手动维护——它只在显式用 GRANT ... ON db.tbl(col1,col2) 时写入，且优先级高于表级权限。不过现在基本没人这么干，因为 ORM 和查询生成器很难适配列级权限，一开就容易报 Column 'xxx' in field list is ambiguous。

另外别被 performance_schema 里的 users 表误导，它只记录当前活跃连接的账号信息，不反映权限，字段也少得多。

• mysql.columns_priv 的 Column_name 是 BINARY 类型，大小写完全敏感，'id' 和 'ID' 是两回事
• MySQL 8.0+ 默认关闭列权限检查（check_proxy_users=OFF），除非明确 SET PERSIST check_proxy_users = ON，否则改了 columns_priv 也没用
• 权限校验路径很长：连接阶段看 user → 库操作看 db → 表操作看 tables_priv → 列操作才落到 columns_priv，中间任意一层 deny 就终止

权限系统最麻烦的不是字段多，而是匹配顺序和缓存机制——GRANT 之后记得 FLUSH PRIVILEGES，查权限优先用 SHOW GRANTS，别信自己手写的 SELECT 语句。表结构只是快照，运行时权限树才是真相。