如何配置用户仅能访问特定的表_表级权限(Table-specific)授予方案-phpMyAdmin-PHP中文网

postgresql中应显式授予表级select权限（如grant select on table orders to app_reader），避免on all tables导致失控；非public schema需额外grant usage；须revoke create防止干扰；权限在语句执行时校验，旧连接不立即失效。

postgresql 中如何用 grant 控制用户只能查某张表

直接给 select 权限到具体表，而不是数据库或 schema；不授 usage 给 schema 也没关系——只要没给 schema 级权限，用户连 \dt 都看不到其他表名。

常见错误是只执行 GRANT SELECT ON ALL TABLES IN SCHEMA public TO user1，这会把后续新建的表也自动授权，失控风险高；更稳妥的是显式指定表名。

GRANT SELECT ON TABLE orders TO app_reader —— 最小权限，精准控制
如果表在非 public schema（比如 analytics），必须先确保用户有该 schema 的 USAGE 权限，否则即使有表权限，SELECT * FROM analytics.orders 仍报错 permission denied for schema analytics
别忘了 REVOKE CREATE ON SCHEMA public FROM user1，否则用户可能在 public 下建表干扰隔离

MySQL 8.0+ 表级权限需要先关掉 sql\_mode=‘NO\_FOREIGN_KEY_CHECKS’？

不需要。MySQL 表级权限和 foreign key 检查完全无关。真正卡住的是权限生效机制：MySQL 不支持“只给某张表的 SELECT”，必须配合 GRANT ... ON database.table 语法，且 database 名不能省略或写成 *。

典型错误现象：GRANT SELECT ON orders TO 'u'@'localhost' 报错 Access denied; you need (at least one of) the SUPER privilege(s) —— 实际只是因为没写库名。

正确写法：GRANT SELECT ON myapp.orders TO 'u'@'localhost'
用户登录后默认 schema 是空的，SELECT * FROM orders 会失败，必须显式写 SELECT * FROM myapp.orders 或先 USE myapp
MySQL 8.0+ 支持角色（ROLE），但角色本身不能跨库绑定表权限，每个 GRANT 仍需明确库名+表名

SQL Server 中 DENY 优先级高于 GRANT，但容易误判失效

SQL Server 的权限模型里，DENY 确实会覆盖同级 GRANT，但它只对「直接授予的对象」生效。如果用户属于某个 Windows 组或数据库角色，而该角色被 DENY 了某张表，那用户照样进不去——哪怕你单独给他 GRANT 了同一张表。

错误调试场景：执行了 GRANT SELECT ON dbo.logs TO appuser，但查询仍报 The SELECT permission was denied on the object 'logs'。

用 SELECT * FROM fn_my_permissions(NULL, 'DATABASE') 查当前会话实际拥有的数据库级权限
用 SELECT class_desc, permission_name, state_desc FROM sys.database_permissions WHERE major_id = OBJECT_ID('dbo.logs') 看这张表上有没有残留的 DENY 记录
最常被忽略的一点：SQL Server 默认给 public 角色在 INFORMATION_SCHEMA 和 sys 视图上的 SELECT 权限，但如果你 DENY 过整个 schema，这些系统视图也会被锁死，导致工具连表结构都读不出来

权限变更后连接池里的旧连接是否立即失效

不会。PostgreSQL、MySQL、SQL Server 都是在语句执行时做权限校验，不是在连接建立时。所以改完权限后，已存在的连接仍按旧权限运行，直到下次执行 SQL 才触发检查。

这意味着：你刚 revoke 了某用户的表权限，但他正在跑的 long-running query 还能继续，下一条语句才会失败；反过来，grant 后他也不能立刻访问，得等新 query 发起。

连接池（如 PgBouncer、HikariCP）通常复用连接，所以应用层可能“感知延迟”几秒到几分钟，取决于连接空闲超时和验证策略
PostgreSQL 可手动发 DISCARD ALL 强制清空 session 级缓存（包括权限上下文），但生产环境慎用
真正要立竿见影，得让应用重建连接——比如滚动重启服务，或配置连接池的 validationQuery 为 SELECT 1 并开启 testOnBorrow

权限粒度越细，依赖的上下文越多：schema 名、库名、角色继承链、连接生命周期……漏掉任意一环，表面配置了，实际还是通不过。