看看大家现在用 pg 的最佳实践是怎么样的

[anivie]

一直把 mysql 当大号 excel 用，最近开了个新坑，直接上了 pg ，让 AI 来指导数据库管理，但是没什么经验不知道 AI 的建议该不该遵循
比如 AI 好像很青睐一个叫 RLS 的特性，业务代码里查询的时候都不带鉴权条件的，所有鉴权都依赖 RLS 来完成，看上去好像很厉害的样子，不知道坑大不大？
感觉以前学的那些数据库知识几乎没什么能用的，越来越脱节了

[hellomsg]

那如果我想跳过 RLS ，查询出所有行呢？比如我是管理员

[xudong]

@hellomsg 可以创建用户或者角色，通过 BYPASSRLS 跳过。
ALTER ROLE user BYPASSRLS;

[Ketteiron]

你先查查 RLS (行级别安全) 相关文档再考虑是否使用。
AI 说的其实没问题，只是稍微理想化，坑确实存在。
曾经用 RLS 设计多租户系统，性能很差，而能用的优化手段有限，不过在量级不大的场景确实会优雅点。
将鉴权逻辑下沉到数据库，有好有坏，具体情况具体分析，有些场景是好的，有些不一定。
但现代化数据库必须提供这样的其他选择，用不用是用户的事。

[hellomsg]

@xudong #2 谢谢🙏

[anivie]

@Ketteiron 这……我查询量还真挺大的，这样看来还是放弃吧 差点踩上了

[Ketteiron]

@anivie #5 跟查询量关系不大，跟查询是否复杂有关，例如有时候缓存会意外失效
https://www.reddit.com/search/?q=PostgreSQL+RLS+index+usage
复杂项目的多租户远比 Supabase 这种理想多租户复杂，简单场景下 RLS 的开销与 where 子句相比可以忽略。

[bronyakaka]

反正大规模的聚合不适合；另外要弄个定时任务去不停真空分析；优先高版本支持分区表；

[bbbblue]

我记得 RLS 一些灵活点的规则需要配合函数/存储过程吧...光 policy 不太行
之前 supabase 里用了一会儿感觉不太适应

RLS 可以作为防止业务出错的保障。。但是这一层让业务自己处理好更好
还有就是就算用 RLS 业务层的校验也是必不可少的...emmm 咋感觉就有点重复的感觉。。。

比较适合后端没太多东西 一把梭？