PostgreSQL中授予readonly_user只读权限需三步：GRANT CONNECT ON DATABASE、GRANT USAGE ON SCHEMA、GRANT SELECT ON ALL TABLES，并用ALTER DEFAULT PRIVILEGES确保新表生效；MySQL 8.0+推荐用角色统一管理，CREATE ROLE后GRANT权限再GRANT角色给用户，并SET DEFAULT ROLE激活。
PostgreSQL 中如何给 readonly_user 授予指定数据库的只读权限
直接给账号加 select 权限不等于“只读”——漏掉 usage 在 schema 上，连表都看不见；忘了 connect，连库都进不去。
典型操作路径是三步走，缺一不可：
GRANT CONNECT ON DATABASE mydb TO readonly_user;-
GRANT USAGE ON SCHEMA public TO readonly_user;（若用其他 schema，如analytics，需同步替换） GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_user;
注意：SELECT 权限不会自动继承新创建的表。上线后新增表，得补上 ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readonly_user;，否则第二天就查不到新表。
MySQL 8.0+ 使用角色（role）批量管理只读权限
手写一堆 GRANT SELECT ON db1.* 容易漏库、错库，也难回收。MySQL 8.0 起支持角色，更适合分析师账号这类标准化需求。
实操顺序要卡准：先建角色、再赋权、最后把用户加到角色里。中间任何一步颠倒，权限就不生效：
CREATE ROLE 'ro_role';GRANT SELECT ON `sales`.* TO 'ro_role'; GRANT SELECT ON `marketing`.* TO 'ro_role';GRANT 'ro_role' TO 'analyst_2024'@'%';-
SET DEFAULT ROLE 'ro_role' FOR 'analyst_2024'@'%';（这句漏了，登录后权限不自动激活）
验证是否生效？别只查 SHOW GRANTS FOR 'analyst_2024'@'%';，还得实际连进去跑 SELECT 1 FROM sales.orders LIMIT 1; —— MySQL 的权限缓存有时延迟，FLUSH PRIVILEGES; 并不能解决角色未默认激活的问题。
连接串里带密码？pgpass.conf 或 .my.cnf 更安全
分析师用 Tableau / Power BI 连数据库时，常把密码明文写在连接配置里。一旦导出或截图，权限就裸奔了。
PostgreSQL 推荐用 ~/.pgpass 文件（权限必须 0600）：
localhost:5432:mydb:readonly_user:secret123
MySQL 对应的是 ~/.my.cnf：
[client] host=localhost port=3306 database=mydb user=readonly_user password=secret123
两者的共同坑点：文件路径和权限不对，工具会静默 fallback 到无认证或报错 authentication failed，但错误信息里完全不提配置文件问题。
为什么 REVOKE INSERT, UPDATE, DELETE 不够用
有人觉得“只要收回写权限就行”，结果发现用户还能删表、清空数据、甚至 DROP SCHEMA。根本原因是 PostgreSQL/MySQL 的权限模型分层：对象级权限（如 SELECT）和 DDL 级权限（如 TRUNCATE、DROP TABLE）是独立控制的。
必须显式禁止这些高危操作：
- PostgreSQL：
REVOKE TRUNCATE ON ALL TABLES IN SCHEMA public FROM readonly_user;（新表也要靠DEFAULT PRIVILEGES补） - MySQL：
REVOKE DROP, ALTER, CREATE ON `mydb`.* FROM 'analyst_2024'@'%';
更隐蔽的是临时表和函数执行权限。如果 DBA 创建过带 SECURITY DEFINER 的函数，且用户有 EXECUTE 权，可能绕过只读限制——这类细节，多数权限检查脚本会忽略。
