MySQL表级权限必须写为db_name.table_name格式，如GRANT SELECT,INSERT ON mydb.users TO 'alice'@'localhost'；仅写表名会报错或误授库级权限，且不支持字段级INSERT/UPDATE/DELETE控制。
GRANT 语句对单张表生效的写法
MySQL 表级权限必须显式指定数据库名和表名，不能只写表名。漏掉 db_name.table_name 格式，权限会加到整个库甚至全局，这是最常踩的坑。
正确写法是：GRANT SELECT, INSERT ON mydb.users TO 'alice'@'localhost';
- 必须带数据库前缀，
GRANT SELECT ON users TO ...是无效的，MySQL 会报错ERROR 1144 (42000): Illegal GRANT/REVOKE command - 支持通配符但仅限表名：
mydb.`log_%`可以匹配log_2024、log_errors，但`mydb`.*是库级，不是表级 - 如果用户尚不存在，
GRANT不会自动创建用户；得先CREATE USER或用GRANT ... IDENTIFIED BY（5.7+ 已弃用该用法）
REVOKE 后权限没立刻失效？检查 FLUSH PRIVILEGES
执行 REVOKE 后某些客户端仍能操作旧权限，不是 bug，而是权限缓存没刷新。
MySQL 权限变更后，已连接的客户端会继续使用内存中的权限副本，直到重连或手动刷新。
- 运行
FLUSH PRIVILEGES;强制重载权限表（mysql.tables_priv等），所有活跃连接立即生效 - 不建议依赖它做高频权限开关——频繁刷权限会影响性能，且无法精确控制某一个连接
- 更稳妥的做法是：
REVOKE+ 让应用重连，或限制在低峰期操作
INSERT/UPDATE/DELETE 权限对字段级无约束
MySQL 的表级 INSERT、UPDATE、DELETE 权限不区分字段，只要拥有就可操作整行。想限制字段，必须用视图或应用层拦截。
例如：GRANT UPDATE ON mydb.users TO 'editor'@'%'; 允许修改 users 表任意字段，包括 password、is_admin。
-
SELECT支持字段级授权：GRANT SELECT(id, name) ON mydb.users TO ...，但其他 DML 不行 - 试图用
UPDATE(name)授权会报错：ERROR 1064 (42000): You have an error in your SQL syntax - 敏感字段保护只能靠视图封装（如只暴露非密码字段）或 ORM 层过滤，MySQL 原生不提供字段级写权限
权限继承关系导致表级设置被覆盖
用户可能同时拥有库级、全局级权限，此时表级 REVOKE 会被更高优先级权限绕过。MySQL 权限检查顺序是：列 → 表 → 数据库 → 全局。
比如用户有 GRANT SELECT ON mydb.* TO ...，再单独 REVOKE SELECT ON mydb.audit_log，实际仍能查 audit_log —— 因为库级权限覆盖了表级拒绝。
- MySQL 没有 DENY 语句，只有 GRANT 和 REVOKE，而 REVOKE 只能撤回你曾经 GRANT 过的权限
- 若想真正禁止访问某张表，必须确认该用户在所有更高级别（库、全局）都没有对应权限
- 查当前用户有效权限用：
SHOW GRANTS FOR 'user'@'host';，注意输出中是否有更宽泛的条目
权限系统本身不复杂，难的是理清层级叠加后的实际效果。很多人调了半天发现权限没起作用，最后发现是库级权限还开着——这种问题没法靠试错解决，得先看 SHOW GRANTS 把当前策略摊开。
