用途：系统性地提升 Supabase 查询与数据库性能，分三层推进——PostgreSQL 引擎（索引、查询计划、物化视图）、Supabase 基础设施（Supavisor 连接池、Edge Functions、只读副本）、客户端 SDK 模式（列选择、分页、RPC 函数）。所有技术都要求可测量，用 EXPLAIN ANALYZE 前后对比确认改进。
前提：已安装 @supabase/supabase-js v2+ 的 Supabase 项目（本地或托管）、Supabase CLI（npx supabase --version 验证）、可访问 Dashboard 的 SQL Editor 或直连 Postgres、启用 pg_stat_statements 扩展。
主要能力与用法：
- 诊断：启用 CREATE EXTENSION IF NOT EXISTS pg_stat_statements; 按平均执行时间查最慢查询；用 npx supabase inspect db index-usage、cache-hit、table-sizes 检查索引使用与缓存命中；查 pg_stat_activity 判断连接池问题。
- 索引与查询计划：用 EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) 读计划，关注大表 Seq Scan；创建基础、复合、部分索引；查询缺失的外键索引与未使用索引；生产表用 CREATE INDEX CONCURRENTLY 避免写锁。
- 客户端与基础设施：避免 select('*')，只选所需列；用 .range() 分页；用 RPC 函数把复杂聚合下推到 Postgres；用物化视图预计算并配合 REFRESH MATERIALIZED VIEW CONCURRENTLY 刷新；服务端无服务器环境用 Supavisor 事务模式连接串并降低 max 池大小；用 Edge Functions 就近计算；Pro+ 计划可启用只读副本分流读密集负载。
适用场景：慢查询排查、JOIN 与聚合性能优化、无服务器部署连接耗尽、响应体过大、物化视图数据陈旧、缓存命中率偏低等。
限制：只读副本需 Pro+ 计划；物化视图需自行安排刷新（pg_cron 或 cron Edge Function）；RLS 策略中的逐行子查询会拖慢查询，需改用 security definer 函数或 EXISTS；缓存命中率低于 99% 通常需升级计算附加组件或减少访问页数。具体收费与价格资料未提供。