Supabase 的 RLS 行级安全怎么配

Supabase 数据库变慢，常见症状有哪些

Supabase 上的 Postgres 性能问题往往以几种典型症状出现：接口超时、查询慢得离谱，多半是慢查询或缺了索引；频繁报 Too many connections，通常是连接池配置或连接泄漏；开了行级安全（RLS）之后接口突然变慢，问题常在策略函数的写法和它能不能用上索引；还有表数据量涨上来后，没有合适的复合索引或分区，查询逐渐拖垮。这些症状有时单独出现，有时几个叠在一起，单靠肉眼看 SQL 很难判断根因。

这个技能能帮你诊断和改什么

它的工作方式是"先取证、再开方"：要求先读取相关规则、收集诊断数据，再按 Too many connections、慢查询、RLS 变慢、连接池配置或多症状这几类问题选择对应的工作流或参考规则，通过必要的门禁查询后才给建议，避免凭经验误判。覆盖的诊断维度包括查询性能、连接管理、安全 RLS 和 Schema 设计，可以定位慢查询的成因、缺失的索引、连接耗尽、RLS 策略的性能开销，并给出复合索引、部分索引、分区方案、权限检查和连接池配置。关键是每条修改建议都配 EXPLAIN 验证步骤，让你能确认改动真的生效。

把"先收集证据再下结论"做成强制门禁，正是这套实践和随手调优的区别：数据库性能问题最忌猜，EXPLAIN 验证保证给出的索引或改写确实改善了执行计划，而不是看起来合理。

怎么用它

用法是把数据库当前的症状用自然语言描述给它，由它按流程取证、定位并给出可验证的方案。例如可以这样对它说：

它适合这些场景：Supabase 项目出现慢查询、超时或 Too many connections 错误；启用 RLS 后接口变慢、需要检查策略函数和索引使用；表增长后要设计复合索引、部分索引或分区策略；上线前要审查 SQL、权限、连接池和监控配置是否安全。适合 Supabase 开发者、后端工程师、数据库管理员、全栈团队，以及要优化 Postgres 性能与安全策略的技术负责人。

大家常问

Supabase 的 RLS（行级安全）到底是什么，为什么一定要开

RLS 是 Postgres 内置的行级安全：把"哪一行谁能看、谁能改"的规则下沉到数据库，执行每条 SQL 时逐行评估策略，返回 true 才放行。Supabase 客户端直连数据库，不开 RLS 时任何拿到 anon key 的人都能读全表，所以它是匿名访问下的最后一道防线。

为什么 Supabase 开了 RLS（行级安全）之后接口反而变慢了

RLS 不是查询前的一次性闸机，而是给每行追加策略判断的 WHERE。最常见的坑是策略里裸写 auth.uid()，它会被逐行调用；用 (SELECT auth.uid()) 包一层就只算一次。另外策略涉及的列若没建索引，会退化成全表扫描，表越大越慢。

为什么 Postgres 查询缺了索引就会变慢

没有索引时 Postgres 只能顺序扫描（Seq Scan），从头到尾逐页读完整张表再筛选，代价随行数线性增长；有 B-Tree 索引则直接定位到目标行，代价几乎恒定。表越大差距越大，百万行级别可相差上万倍，EXPLAIN 里能直接看到 Seq Scan 还是 Index Scan。

Supabase 为什么会报 Too many connections（连接数爆掉）

Postgres 是进程模型，每个连接占 1-3MB 内存且套餐有上限，超过 max_connections 就拒绝新连接。常见原因是应用没走连接池、Serverless 函数每次冷启动都新建连接、连接泄漏未归还，或直连 5432 而非走 PgBouncer 的 6543 端口。改用连接池复用少量真连接即可缓解。