mysql权限系统是什么_mysql用户与权限管理概念

mysql权限系统基于“用户+主机”双因子认证，分全局、库、表、列四级授权，权限追加不覆盖，’localhost’与’%’为不同账户，权限修改后需FLUSH PRIVILEGES（仅手动改表时），已连接会话权限不变。

Mysql权限系统是一套基于“用户+主机”双因子认证、分层授权的访问控制机制，它不是简单的“谁能登录”，而是精确到“谁从哪来、能操作哪个库/表/列、能执行什么动作”。

它的核心判断逻辑只有两步：先看 user 表里有没有匹配的 'user'@'host' 记录（连得上吗？），再查 user、db、tables_priv 等权限表，按层级从高到低逐级叠加生效（能做什么？）。

权限不是全局开关，而是分层叠加的“能力包”

MySQL把权限拆成四级，每级覆盖范围不同，且低层级权限会覆盖（或补充）高层级限制：

• .*（全局）：写成 GRANT select ON *.*，权限存进 mysql.user 表，影响所有数据库——慎用，比如开了 delete 就等于能删任意库的任意行；
• database.*（库级）：如 GRANT INSERT ON app_db.*，权限存在 mysql.db 表，只对指定库生效；
• database.table（表级）：权限存 mysql.tables_priv，例如只允许查 users 表但不能碰 logs；
• database.table(column)（列级）：最细粒度，比如只开放 SELECT(name, email)，隐藏 password_hash 列。

注意：GRANT 不是覆盖式写入，而是“追加式授权”。你反复执行 GRANT SELECT ON db1.* TO 'u'@'%' 不会报错，但也不会去重——权限只会越授越多，直到你显式 REVOKE。

‘localhost’ 和 ‘%’ 是两个完全不同的用户身份

这是最容易踩坑的地方。MySQL 把 'app'@'localhost' 和 'app'@'%' 当作两个独立账户，各自有独立密码、独立权限记录：

• 'app'@'localhost'：只能通过 unix socket 或 127.0.0.1 连接，走本地认证路径；
• 'app'@'%'：允许从任意远程 IP 连接，但若 MySQL 配置了 skip-networking 或防火墙拦截 3306，照样连不上；
• 如果只创建了 'app'@'localhost' 却试图从 docker 容器或另一台机器连，会直接报错 access denied for user 'app'@'172.18.0.3'——因为那条记录根本不存在。

验证方法很简单：

SELECT host, user, authentication_string FROM mysql.user WHERE user = 'app';

权限变更不会实时生效，必须刷新或重连

MySQL 启动时把权限表加载进内存，后续所有权限检查都走内存副本。这意味着：

• 你执行 GRANT 或 REVOKE 后，新权限**立即生效**（只要语句成功）；
• 但如果你是直接 UPDATE mysql.user 或 INSERT INTO mysql.db 修改权限表，**必须执行 FLUSH PRIVILEGES; 才能生效**；
• 已存在的连接不受影响——当前会话仍保持旧权限，新连接才用新规则；
• 使用 CREATE USER / GRANT 创建的用户，不需要 FLUSH；手动改表才需要。

顺带一提：DROP USER 'u'@'h' 在 MySQL 5.7+ 会自动清理对应权限记录；但如果是老版本，得先 REVOKE 再 DROP，否则残留权限可能引发混淆。

真正难的不是记命令，而是想清楚“这个用户到底该从哪来、要动哪些数据、能不能转授权限”。比如给应用账号开 GRANT OPTION，等于给了它建小号的权利——这在生产环境几乎从不被允许。