PostgreSQL中批量授权最稳妥方式是GRANT ON ALL TABLES/SEQUENCES/FUNCTIONS配合ALTER DEFAULT PRIVILEGES，且须以schema owner身份执行，默认权限不自动跨schema生效。
PostgreSQL 中用 GRANT ... ON ALL TABLES IN SCHEMA 批量授权给角色
直接对角色批量授多表权限，最稳妥的方式不是逐个 grant，而是利用 schema 级别批量语法。它能覆盖当前已存在且未来新创建的表（需配合 alter default privileges），避免漏表或重复操作。
常见错误是只执行 GRANT ON ALL TABLES 却忽略 GRANT ON ALL SEQUENCES 和 GRANT ON ALL FUNCTIONS——尤其当表含 SERIAL 主键或函数被调用时，用户会报错 permission denied for sequence 或 permission denied for function。
GRANT SELECT, INSERT ON ALL TABLES IN SCHEMA public TO analyst_role;GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO analyst_role;GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO analyst_role;
注意：该命令只影响执行时刻已存在的对象，不自动作用于后续新建表。
让新表自动继承权限：必须配 ALTER DEFAULT PRIVILEGES
否则每次 CREATE TABLE 后都要手动补授权，违背“简化管理”初衷。关键点在于：默认权限绑定的是「发出命令的角色」，不是目标角色——也就是说，你要以拥有 schema 权限的用户（如 postgres 或 schema owner）身份执行，默认权限才生效。
典型误操作：用 analyst_role 自己去执行 ALTER DEFAULT PRIVILEGES，结果毫无效果，因为该角色没权设置默认策略。
- 以 schema owner 身份执行：
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT ON TABLES TO analyst_role; - 同样要为序列和函数单独设：
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON SEQUENCES TO analyst_role; - 默认权限不递归到其他 schema，每个需要管理的 schema 都得单独配置
MySQL 8.0+ 用角色（ROLE）替代用户组，但权限仍按对象粒度授予
MySQL 没有 schema 级批量授权语法，也没有 DEFAULT PRIVILEGES。所谓“简化管理”，本质是把权限先赋给角色，再把角色赋予用户。但每张表、每个库的权限仍得显式声明。
容易踩坑的是跨库场景：若用户需访问 sales_db 和 reporting_db，必须分别对两个库执行 GRANT SELECT ON sales_db.* TO 'analyst_role'@'%';，不能写成 GRANT SELECT ON *.*——那会过度授权，且 MySQL 8.0 默认禁止通配符全局授权。
- 创建角色：
CREATE ROLE 'analyst_role'; - 授库级权限：
GRANT SELECT, INSERT ON sales_db.* TO 'analyst_role'; - 用户绑定角色：
GRANT 'analyst_role' TO 'alice'@'%'; - 启用角色需执行：
SET ROLE 'analyst_role';（或在用户登录时默认激活）
权限变更后，连接不立即生效？检查 REVOKE 是否残留 + 连接复用
加了权限但应用连不上，大概率不是授权没生效，而是旧连接缓存了权限状态。PostgreSQL 和 MySQL 均不支持运行时刷新单个连接的权限缓存。
更隐蔽的问题是残留 REVOKE：比如之前执行过 REVOKE INSERT ON TABLE t1 FROM analyst_role，后来又 GRANT INSERT ON ALL TABLES，但 t1 不在“ALL TABLES”生效范围内（因它是 revoke 后创建的？不，关键是 revoke 优先级高于 grant，且不会被 all-tables 覆盖）。
- 查当前角色实际权限：
\z（psql）或SHOW GRANTS FOR 'analyst_role';（MySQL） - 确认无冲突
REVOKE记录，必要时显式GRANT ... ON TABLE t1覆盖 - 应用侧需重建数据库连接，不能复用旧连接
权限系统本身不复杂，难的是理清“谁在什么上下文下执行了哪条语句”，尤其是跨角色、跨 schema、跨时间的操作叠加。动手前，先用 \du+ 或 SELECT * FROM pg_roles 看清角色层级，比盲目重跑授权更省时间。
