为何无行级策略时，带security_barrier的视图查询仍大幅变慢？

问题背景 #

开发应用时采用PostgreSQL内置的行级安全（RLS）功能，为确保视图遵循RLS规则，给视图启用了security_barrier和security_invoker选项，但某一关联查询的执行时间从毫秒级飙升至20秒以上。

复现示例 #

-- 基础表定义
CREATE TABLE foo (
    name varchar(20),
    id uuid
);

CREATE INDEX IF NOT EXISTS foo_idx ON foo (name);

CREATE TABLE bar (
    id uuid primary key,
    some_data text  -- 增大单条数据体积，放大顺序扫描的性能损耗
);

-- 生成测试数据
INSERT INTO bar (id, some_data)
SELECT gen_random_uuid(), repeat(md5(random()::text) || md5(random()::text), 10)
FROM generate_series(1, 100000);

INSERT INTO foo (name, id)
SELECT substr(md5(random()::text), 0, 5), bar.id FROM bar;

-- 带安全屏障的问题视图
CREATE VIEW bar_protected WITH (security_barrier) AS (
    SELECT * FROM bar
);

• 慢查询：SELECT * FROM foo INNER JOIN bar_protected ON bar_protected.id = foo.id WHERE foo.name LIKE 'ab%' LIMIT 10
• 快速等效查询：SELECT * FROM foo INNER JOIN bar ON bar.id = foo.id WHERE foo.name LIKE 'ab%' LIMIT 10

性能瓶颈分析 #

security_barrier的设计目标是阻止恶意用户通过操纵执行计划泄露未授权数据，因此PostgreSQL会强制限制优化器对视图的谓词下推操作。在慢查询中，优化器无法将foo.name LIKE 'ab%'的过滤条件提前应用，只能先对bar表执行全表顺序扫描，再与foo表的全部数据关联后进行过滤，导致大量不必要的数据读取。而直接关联表时，优化器可以先通过foo的name索引快速筛选出少量匹配行，再利用bar的主键索引精准定位对应记录，大幅减少数据处理量。

解决方案 #

1. 使用查询提示强制走索引 #

PostgreSQL 12及以上版本支持查询提示，可指定对视图关联的表使用索引扫描，绕过全表顺序扫描：

SELECT /*+ IndexScan(bar_protected bar_pkey) */
       * 
FROM foo 
INNER JOIN bar_protected ON bar_protected.id = foo.id 
WHERE foo.name LIKE 'ab%' 
LIMIT 10;

其中bar_pkey是bar表的主键索引名，通过提示引导优化器优先使用索引查找数据。

2. 评估并调整视图安全属性（谨慎操作） #

如果视图的RLS策略明确不会存在数据泄露风险，可临时关闭视图的security_barrier属性（仅适用于视图本身无敏感过滤逻辑的场景）：

ALTER VIEW bar_protected SET (security_barrier = off);

此操作会失去安全屏障的保护，需严格评估业务安全性后执行。

3. 重构视图逻辑适配过滤场景 #

若过滤条件相对固定，可将foo表的过滤逻辑整合到视图中，让优化器提前完成数据筛选：

CREATE VIEW bar_protected WITH (security_barrier) AS (
    SELECT bar.* 
    FROM bar
    JOIN foo ON bar.id = foo.id
    WHERE foo.name LIKE 'ab%'
);

该方案适用于过滤条件固定的场景，动态条件下不适用。

4. 升级PostgreSQL版本（可选） #

PostgreSQL 16及以上版本对RLS和安全屏障视图的执行计划优化有显著提升，优化器能更智能地处理安全视图的关联逻辑，可能自动避免不必要的全表扫描。

内容的提问来源于stack exchange，提问作者Evert Heylen