GRANT SELECT未生效主因是未指定schema、host不匹配、缺少USAGE权限、对象类型不符或DENY优先级覆盖；须按数据库特性逐一排查schema、host、object_type、role及deny规则。
GRANT SELECT 为什么执行后还是报错 “permission denied for table”
权限没生效，大概率是没指定 schema。postgresql 和大多数兼容 sql 标准的数据库（如 greenplum、edb）中，grant select on 表名 默认只作用于当前搜索路径里的同名表，如果表在 public 以外的 schema（比如 sales），光写表名会失败或静默忽略。
- 必须显式写成
GRANT SELECT ON TABLE schema_name.table_name TO username - 查表所在 schema：用
SELECT table_schema FROM information_schema.tables WHERE table_name = 'your_table'; - 如果用户连
schema的USAGE权限都没有，即使表上给了SELECT，照样查不了——得补一句GRANT USAGE ON SCHEMA schema_name TO username;
MySQL 里 GRANT SELECT 不生效？注意用户 host 匹配规则
MySQL 的权限是按 'username'@'host' 组合粒度控制的，GRANT SELECT ON db.table TO 'u1' 实际等价于 'u1'@'%'，但如果你登录时用的是 'u1'@'localhost'，这两者不等价，权限不会命中。
- 确认当前连接用户：
SELECT CURRENT_USER(); - 授予权限时务必匹配 host，比如
GRANT SELECT ON mydb.orders TO 'u1'@'localhost'; - 改完权限后别忘了
FLUSH PRIVILEGES;（仅 MySQL 5.7 及更早版本严格需要；8.0+ 在多数情况下自动刷新，但手动执行更稳妥）
Oracle 中 GRANT SELECT 需要额外考虑对象类型和同义词
Oracle 里 GRANT SELECT ON table_name 只对基表或视图有效；如果是物化视图、序列、甚至某些带函数索引的表，语法一样但行为可能受限。更常见的是：用户通过同义词访问表，但权限授予的是原表，而同义词所在 schema 没开 SELECT_CATALOG_ROLE 或没授权访问同义词本身。
- 先确认对象类型：
SELECT object_type FROM all_objects WHERE object_name = UPPER('table_name'); - 如果用的是私有同义词，被授权用户还需有该同义词所在 schema 的
SELECT权限，或使用公有同义词 - 跨 schema 授予时，注意是否启用了 Oracle 的“细粒度访问控制”（FGAC），它可能覆盖或拦截
GRANT效果
SQL Server 的 GRANT SELECT 要小心角色继承和 DENY 优先级
SQL Server 权限模型里，DENY 永远高于 GRANT，哪怕 GRANT 是后来加的。而且权限可以来自多个角色（db_datareader、自定义角色等），一旦其中任一角色含 DENY SELECT，整个查询就会被拒。
- 查用户实际权限：运行
SELECT * FROM fn_my_permissions(NULL, 'DATABASE');或用sys.database_permissions视图 - 检查是否存在
DENY记录：SELECT * FROM sys.database_permissions WHERE permission_name = 'SELECT' AND state_desc = 'DENY'; - 避免混用
db_owner和细粒度GRANT：前者权限太大，容易掩盖真实问题；调试时建议用最小权限角色测试
权限这事，表面就一条语句，背后绑定着 schema、host、object type、role 层级、deny 优先级……漏掉任意一环，GRANT SELECT 就像发了条没填收件人地址的快递。
