REFERENCES权限仅控制用户能否在新建表中定义外键约束，不涉及对被引用表的数据操作权限；需对被引用表（而非外键所在表）授予表级REFERENCES权限，且不可按列授权。
PostgreSQL 中 REFERENCES 权限到底管什么
它只控制用户能否在自己创建的表里定义外键（foreign key），不涉及查、改、删被引用的表数据，也不影响 select 或 update 被引用列。常见误解是以为授了 references 就能“操作关联表”，其实只是“建约束”的通行证。
典型错误现象：ERROR: permission denied for table users —— 实际是因为建外键时没对 users 表有 REFERENCES 权限，而非没 SELECT 权限。
- 必须授予被引用表（即主键/唯一键所在表）的
REFERENCES权限，不是授予外键所在表 - 权限粒度是表级，不能按列限制（哪怕只引用其中一列）
- 若被引用表使用的是复合主键，仍只需整表授
REFERENCES，无需额外操作
怎么给用户授 REFERENCES 权限（PostgreSQL）
用 GRANT REFERENCES ON TABLE，不是 GRANT REFERENCES ON COLUMN（后者语法无效）。
示例：让角色 app_writer 能在新建表中引用 public.users 的主键：
GRANT REFERENCES ON TABLE public.users TO app_writer;
- 如果表在非
publicschema，必须写全 schema 名，比如GRANT REFERENCES ON TABLE auth.users TO app_writer - 不能用通配符（如
GRANT REFERENCES ON TABLE * TO ...），需逐表授权 - 授予
REFERENCES不自动赋予SELECT，若建外键后还需查被引用数据，得单独GRANT SELECT
MySQL 里没有 REFERENCES 权限这回事
MySQL 5.7+ 默认忽略外键权限检查；即使启用 foreign_key_checks=1，也**不校验用户是否有权限建外键**。只要用户有 CREATE 和 ALTER 表权限，就能加外键——REFERENCES 权限在 MySQL 的权限系统里纯属占位符，不生效。
所以你在 MySQL 执行 GRANT REFERENCES ON ... 不报错，但也没任何实际作用。
- 真正起作用的是
CREATE（建表）、ALTER（改表结构）权限 - 想阻止用户加外键？只能收走
ALTER权限，或用代理层/应用层拦截 DDL - MySQL 8.0 的角色机制同样不改变这一事实：
REFERENCES在SHOW GRANTS里会出现，但不参与权限判定
容易被忽略的依赖链问题
如果表 A 引用表 B，而你只给用户授了 A 的 REFERENCES，但没授 B 的——建外键会失败；反过来，如果已存在外键，之后撤回被引用表的 REFERENCES 权限，**已有外键不受影响**，也不会失效。
- 权限只在校验 DDL 时起作用（
CREATE TABLE/ALTER TABLE ADD CONSTRAINT） - 撤销权限后，用户仍可
SELECT、UPDATE已存在的外键列，只要其他权限允许 - 跨库引用（如 PostgreSQL 的外部表、MySQL 的 FEDERATED）不适用这套权限模型，得看具体扩展机制
外键权限这件事，本质是 DDL 阶段的一次性校验开关，不是运行时的访问控制锁。很多人卡在建表那一步，回头翻权限列表才发现漏了被引用表——盯住那个“被引用”的表名，别只看自己要建的表。
