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

This topic created in 226 days ago, the information mentioned may be changed or developed.

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

rls

9 replies • 2025-10-24 08:09:51 +08:00

hellomsg

Oct 23, 2025

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

xudong

Oct 23, 2025

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

Ketteiron

Oct 23, 2025

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

hellomsg

Oct 23, 2025

@xudong #2 谢谢🙏

anivie

Oct 23, 2025

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

差点踩上了

Ketteiron

Oct 23, 2025

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

bronyakaka

Oct 23, 2025

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

bbbblue

Oct 24, 2025

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

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

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

iseki

Oct 24, 2025 via Android

RLS 需要依赖 PostgreSQL 自己的权限/用户系统，这个东西在现在来说不是很实用。多租户的话一般建议用 schema 切分，也有利于降低租户之间的耦合。