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，等于给了它建小号的权利——这在生产环境几乎从不被允许。
