GRANT语句严格按全局、数据库、表、列等层级授予权限，低层级不覆盖高层级限制；权限变更需新建连接生效，FLUSH PRIVILEGES对已连会话无效；MySQL 8.0起须CREATE USER后GRANT，禁用IDENTIFIED BY；REVOKE仅移除指定权限，不删用户。
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 会导致缓存不一致，极难调试。
