MySQL单表权限需显式指定库名、清理粗粒度权限并刷新生效；漏写库名、残留库级权限或未执行FLUSH PRIVILEGES是授权无效的三大主因，视图才是字段与逻辑隔离的可靠方案。
MySQL 支持对单张表做精确权限控制，但必须显式指定数据库名、避免权限叠加、且需刷新生效；漏写库名、残留库级权限或未执行 FLUSH PRIVILEGES 是最常导致“授权了却没用”的三个原因。
GRANT 语句必须带库名和点号，不能只写表名
MySQL 不会自动把 GRANT SELECT ON users TO 'u'@'%' 理解为你想授权目标库下的 users 表——它默认作用于当前默认库（通常是 mysql），极大概率授错对象。
正确写法必须包含完整路径：
-
GRANT SELECT, INSERT ON app_db.users TO 'u'@'%'✅ -
GRANT UPDATE(email) ON app_db.users TO 'u'@'%'✅（列级更新） -
GRANT SELECT ON users TO 'u'@'%'❌（授到 mysql.users 或报错） -
GRANT SELECT ON app_db.* TO 'u'@'%'❌（这是库级，不是你想要的“单表”）
先清理更粗粒度权限，否则表级授权无效
MySQL 权限是叠加生效的，且“粗粒度覆盖细粒度”。如果你之前执行过 GRANT SELECT ON app_db.* TO 'u'@'%'，再单独 REVOKE SELECT ON app_db.users 并不会禁掉这张表——因为库级权限还在，它直接盖过了表级限制。
要真正实现“只给某几张表”，必须：
- 先撤掉所有宽泛权限：
REVOKE SELECT ON app_db.* FROM 'u'@'%' - 再逐个授予需要的表：
GRANT SELECT ON app_db.users TO 'u'@'%'、GRANT SELECT ON app_db.orders TO 'u'@'%' - 确认无残留：
SHOW GRANTS FOR 'u'@'%'输出里不应出现ON app_db.*或ON *.*
权限变更后必须 FLUSH PRIVILEGES，且验证要用新连接
MySQL 权限加载进内存后才生效，GRANT 语句多数情况会自动触发刷新，但不保证 100% 实时——尤其在非 root 用户操作或权限表被直改后，FLUSH PRIVILEGES 是唯一可靠手段。
另外，已存在的连接会缓存旧权限，即使你刚刷完，老连接仍按旧规则校验。验证前务必断开重连，或用新客户端测试：
- 执行
FLUSH PRIVILEGES后，用mysql -u u -p -h host新建连接 - 不要在原连接里直接
USE app_db再试，它可能还拿着旧上下文 - 测试语句优先用全限定名：
SELECT * FROM app_db.users，避免因默认库影响判断
视图才是字段级和逻辑隔离的可靠出口
如果目标不只是“访问某张表”，而是“只让看到某几张字段”或“只暴露某个分区的数据”，硬靠表级权限走不通——列级 SELECT(id,name) 易被 JOIN 和子查询绕过；分区根本不可授权。
此时应放弃在权限层兜底，转而用视图构建可控边界：
- 建视图：
CREATE VIEW app_db.safe_users AS SELECT id, name, created_at FROM users - 授视图权限：
GRANT SELECT ON app_db.safe_users TO 'u'@'%' - 同时撤掉基表权限：
REVOKE SELECT ON app_db.users FROM 'u'@'%'
视图天然隔离字段、可封装分区逻辑（如 WHERE dt = '2024-08'），且权限独立管理——这才是生产环境真正能落地的最小权限实践。别指望权限系统替你做过滤，它只做准入检查。
