全局权限必须用.语法，管理类权限（如create user、reload）只能在此层级授予；数据库级权限不自动覆盖新建库；表/列级权限对delete等操作无效；权限变更需重连生效，flush privileges通常非必需。
全局权限只能用 *.* 语法，其他写法直接报错
MySQL强制要求管理类权限（如 CREATE USER、RELOAD、SHUTDOWN、SHOW DATABASES）必须用 ON *.* 授予。哪怕你写成 GRANT CREATE USER ON test.* TO 'u'@'%'，MySQL 会直接拒绝并报错：ERROR 1044 (42000): Access denied。
常见误操作是以为“给某个库授了 ALL 就能建库”，结果执行 CREATE DATABASE newdb 失败——因为 CREATE DATABASE 是全局操作，不依赖库级权限。必须显式执行：GRANT CREATE ON *.* TO 'u'@'%'。
另一个坑是 DROP ON *.*：它允许删任意库，包括 mysql 系统库。一旦误授，可能直接导致权限表损坏、服务不可用。
数据库级权限（db_name.*）不继承新建库
授予 GRANT SELECT ON sales.* TO 'app'@'%' 后，用户能查 sales 库所有表；但之后管理员新建了 logistics 库，该用户默认无权访问——哪怕你用了 sales.* 这种通配写法，它只对当前已存在且名字匹配的库生效，不自动覆盖未来创建的库。
权限检查顺序是全局 → 数据库 → 表 → 列，所以如果用户同时有 SELECT ON *.* 和 REVOKE SELECT ON sales.*，后者无效：全局权限未被显式收回，就仍可查 sales。
SHOW GRANTS FOR 'app'@'%' 只显示最高层级的授权语句（比如只显示 *.*），不会列出被覆盖的下层限制。排查越权时得手动查 mysql.db 表确认实际配置。
表级和列级权限只对部分操作生效
表级权限（db.tbl）控制整张表的操作，比如 GRANT UPDATE ON hr.employees TO 'mgr'@'%' 允许修改整行；但列级权限（GRANT UPDATE(salary) ON hr.employees TO 'mgr'@'%'）只限制字段粒度，且仅对 SELECT、INSERT、UPDATE 有效。
关键限制：DELETE、DROP TABLE、TRUNCATE 这类行级或对象级操作，**完全不认列权限**。哪怕你只给了 salary 列的 UPDATE 权限，用户照样能 DELETE FROM hr.employees 删除整张表数据。
另外，UPDATE 某列时若涉及自增列、默认值或触发器逻辑，还可能隐式需要 INSERT 或 ALTER 权限，否则语句会失败——列权限本身不自动补全这些依赖。
权限存储位置不同，FLUSH PRIVILEGES 并不总是必要
全局权限存于 mysql.user，数据库级存于 mysql.db，表级在 mysql.tables_priv，列级在 mysql.columns_priv。MySQL 在每次连接认证和语句执行时实时读取这些表，不是靠缓存。
所以大多数情况下，GRANT / REVOKE 后权限立即生效，FLUSH PRIVILEGES 并非必需；它只在你绕过 GRANT 直接改系统表（比如用 UPDATE mysql.user）后才需要——但这种操作极危险，容易破坏表结构一致性。
真正容易被忽略的是：权限变更后，已存在的连接不会自动刷新权限。用户必须断开重连，新权限才会对其生效。这点在应用连接池场景下尤其关键——旧连接可能长期持有旧权限，造成策略滞后。
