GRANT 语句的基本语法和权限层级
MySQL 的
GRANT不是“给用户赋权就完事”，它严格区分权限作用域：全局（
*）、数据库（
db_name.*）、表（
db_name.table_name）、列（
(col1, col2)）甚至存储过程。权限在不同层级叠加生效，但低层级权限不能覆盖高层级的显式拒绝（不过 MySQL 不支持
DENY，所以实际是“无权即禁止”）。
常见误操作是直接写
GRANT SELECT ON *.* TO 'u'@'%'，这会授予所有库所有表的查询权——远超业务需要，也违反最小权限原则。
GRANT SELECT, INSERT ON myapp.users TO 'appuser'@'10.20.%.%'—— 仅限指定表
GRANT UPDATE (email, phone) ON myapp.users TO 'support'@'localhost'—— 列级权限，注意括号必须紧贴
UPDATE，不能有空格 全局权限如
RELOAD、
SHUTDOWN只能用
ON *.*，不能限定到库或表
执行 GRANT 后为什么新权限不生效
权限变更不会自动推送到已连接的客户端会话。MySQL 权限检查发生在每个语句执行前，但权限缓存只在连接建立时加载一次。所以即使你
GRANT成功，旧连接仍按老权限运行。
解决方式只有两个：
让应用重建数据库连接（最稳妥） 手动刷新权限缓存：FLUSH PRIVILEGES—— 但这只是重载
mysql系统库中的权限表，并不中断现有连接，对已登录用户无效
注意：
GRANT本身会隐式触发权限表写入，多数情况下无需手动
FLUSH PRIVILEGES；反而是滥用它容易掩盖“没真正连上目标实例”的问题（比如在主从架构里只在从库执行了
GRANT）。
创建用户与授权的原子性问题
MySQL 5.7+ 支持在一条
GRANT语句中自动创建用户，例如：
GRANT SELECT ON sales.* TO 'reporter'@'%' IDENTIFIED BY 'p@ssw0rd123';但该语法在 MySQL 8.0.12+ 已被废弃，改用
CREATE USER+
GRANT分离操作。
更关键的是：如果用户已存在但密码过期、账户锁定（
account_locked = 'Y'），
GRANT仍会成功，但用户无法登录——权限存在，身份验证失败。排查时应先确认：
SELECT user, host, account_locked, password_expired FROM mysql.user WHERE user = 'reporter';MySQL 8.0 推荐流程：先
CREATE USER 'u'@'h' IDENTIFIED WITH caching_sha2_password BY 'pwd'，再
GRANT ...避免用
IDENTIFIED BY在
GRANT中设密码，尤其在自动化脚本里——容易因版本差异失败 使用
SHOW GRANTS FOR 'u'@'h'查看实际生效权限，而非仅信自己刚执行的那条语句
权限回收与撤销的边界行为
REVOKE不是“撤回上一条
GRANT”，而是从权限系统中移除对应项。如果同一用户通过多条
GRANT获得相同权限（比如分别在
db1.*和
db2.*上授了
SELECT），那么只
REVOKE SELECT ON db1.*不会影响
db2.*上的权限。
一个容易忽略的点：
REVOKE ALL PRIVILEGES ON *.* FROM 'u'@'h'并不会删除用户，也不会清除其认证信息；用户依然存在，只是变成“无任何权限”，连
USAGE（空权限）都不剩——此时连
SHOW DATABASES都会被拒绝。 要彻底清理，需组合：
DROP USER 'u'@'h'
REVOKE之后同样需要新连接才能体现效果 没有 “REVOKE … IF EXISTS” 语法，对不存在的权限执行
REVOKE会报错，脚本中需先查
INFORMATION_SCHEMA.ROLE_TABLE_GRANTS或捕获错误
权限系统不是黑盒，它背后是
mysql.user、
mysql.db、
mysql.tables_priv这些表。直接改这些表而不走
GRANT/REVOKE会导致缓存不一致，极难调试。
