PostgreSQL支持TABLE、VIEW、SEQUENCE、FUNCTION单独授权；MySQL 8.0+支持列级权限，5.7仅表级；SQL Server可精确到列但需显式列出。
SQL 权限粒度控制：哪些对象能授、哪些不能授
直接说结论：PostgreSQL 支持对 TABLE、VIEW、SEQUENCE、FUNCTION 单独授权；MySQL 8.0+ 支持列级权限（如 SELECT(col1, col2)），但 5.7 及更早版本不支持列级，只到表级；SQL Server 的 GRANT 可精确到列，但需显式列出列名，漏写就等于没授权。
常见错误现象：GRANT SELECT ON users TO app_user 在 MySQL 5.7 执行成功，但应用仍报“Access denied”，因为实际需要访问的是 users.email 字段，而旧版 MySQL 不认字段级语义，该语句只是授予整表权限——但若账号本身被 REVOKE SELECT ON users 过，或存在更细的 REVOKE SELECT(email)（8.0+ 才有效），就会冲突。
实操建议：
- 先查当前用户实际拥有的权限：
SHOW GRANTS FOR 'app_user'@'%'（MySQL）或\z（psql） - 列级授权只在明确需要隔离敏感字段（如
ssn、password_hash）时启用，否则优先用视图封装 + 表级授权，兼容性更好 - SQL Server 中
GRANT SELECT (name, email) ON dbo.users TO app_role有效，但若后续新增列phone，默认不包含，不会自动继承
事务隔离级别与读一致性：READ COMMITTED 不等于“读最新已提交”
很多人误以为设成 READ COMMITTED 就能实时看到其他事务刚 COMMIT 的数据——其实不是。它只保证本事务内“不会读到未提交的脏数据”，但不保证两次 SELECT 之间能看到新提交的行（即不解决不可重复读）。
使用场景：高并发 OLTP 系统（如订单状态更新）通常用 READ COMMITTED，兼顾性能和基本一致性；金融类强一致场景才上 REPEATABLE READ 或 SERIALIZABLE。
参数差异与坑点：
- PostgreSQL 的
READ COMMITTED每条语句开始时取快照，所以同一事务中两条SELECT可能看到不同版本的数据 - MySQL InnoDB 的
REPEATABLE READ默认启用间隙锁（gap lock），可能引发意外锁等待；而 PostgreSQL 的同名级别不加间隙锁，行为不等价 - SQL Server 的
READ COMMITTED SNAPSHOT（RCSI）是独立开关，需开启数据库级选项ALLOW_SNAPSHOT_ISOLATION = ON和READ_COMMITTED_SNAPSHOT = ON，否则即使设了隔离级别也无效
行级安全策略（RLS）绕过风险：WHERE 条件 ≠ RLS 策略
在 PostgreSQL 中启用了 RLS 后，SELECT * FROM orders WHERE user_id = 123 仍可能返回其他用户的订单——如果策略没覆盖所有访问路径，或者用户有 BYPASSRLS 权限。
根本原因：RLS 是在执行计划生成前注入谓词，但如果你用的是 SECURITY DEFINER 函数，且函数内部做了动态拼接（如 EXECUTE 'SELECT * FROM orders WHERE ' || condition），RLS 策略不会自动生效，因为策略绑定的是表对象，不是字符串查询。
实操建议：
- 启用 RLS 后必须显式为每个角色运行
ALTER TABLE orders ENABLE ROW LEVEL SECURITY，否则策略不激活 - 禁止给应用账号授予
BYPASSRLS，哪怕只用于调试；生产环境应通过专用管理账号操作 - 测试时用普通账号连接，执行
EXPLAIN (VERBOSE) SELECT * FROM orders，确认输出里出现类似Filter: (user_id = current_setting('app.current_user_id'::text)::integer)的策略谓词
连接池与权限上下文丢失：pgbouncer / ProxySQL 不传会话变量
用 pgbouncer 的 transaction 模式时，SET app.user_id = '123' 这类会话变量在事务结束后就被丢弃，下个事务无法继承——这意味着基于 current_setting() 的 RLS 策略会失效。
本质是连接池复用导致会话状态不保留，不是 SQL 层面的问题，但直接影响数据隔离效果。
解决方案取决于你用的中间件：
-
pgbouncer必须切到session模式（牺牲连接复用率），或改用prepared_statement+ 参数化查询传递上下文 - ProxySQL 不支持 PostgreSQL 的会话变量透传，只能靠应用层在每次查询中显式带入（如
SELECT * FROM orders WHERE user_id = $1） - 若用 PgJDBC，可配置
preferQueryMode=simple避免预编译干扰，同时确保currentSchema等关键参数在连接串中固定
最常被忽略的一点：开发时本地直连 PostgreSQL 看起来一切正常，一上生产走 pgbouncer 就出数据越权，问题根源往往不在 SQL 或策略本身，而在连接模式切换带来的上下文断裂。
