PostgreSQL启用RLS时仅用部分索引，查询性能下降问题咨询

启用行级安全（RLS）时无法利用完整索引的核心原因在于RLS策略的过滤条件依赖current_setting函数：

• current_setting属于STABLE级函数，优化器生成执行计划阶段无法确定其返回值（仅能在执行阶段解析），因此无法将RLS的school_id = ...条件与查询中的其他条件结合，利用索引的school_id前缀做高效过滤。
• 表所有者直接指定school_id常量时，优化器能明确该值，可直接匹配索引的school_id前缀，再依次用后续的weekday等字段过滤，走完整的索引扫描路径。
• RLS用户的查询中，优化器仅能识别显式的weekday过滤条件，只能基于索引中的weekday字段做部分过滤，导致执行效率下降。

1. 用Immutable函数封装参数（会话参数固定场景） #

创建IMMUTABLE级函数获取RLS参数，让优化器能提前识别值的稳定性（需确保会话期间参数不会变更）：

CREATE OR REPLACE FUNCTION get_rls_school_id() RETURNS uuid AS $$
BEGIN
  RETURN nullif(current_setting('mm_cloud.rls_restricted_by_school_id', true), '')::uuid;
END;
$$ LANGUAGE plpgsql IMMUTABLE;

-- 更新RLS策略
DROP POLICY "separate_schools" ON "index_test";
CREATE POLICY "separate_schools" ON "index_test"
    USING (school_id = get_rls_school_id());

注意：若会话中需动态修改mm_cloud.rls_restricted_by_school_id参数，此方法不适用（函数会缓存初始值）。

2. 查询时显式指定school_id条件 #

在查询中手动加入与RLS策略一致的school_id过滤条件，让优化器合并显式与隐式条件，利用索引前缀：

SELECT * FROM index_test 
WHERE school_id = nullif(current_setting('mm_cloud.rls_restricted_by_school_id', true), '')::uuid
  AND weekday = 'mo'; -- 替换为你的实际查询条件

此时优化器能识别school_id过滤条件，直接走temp_multiple_idx的完整索引扫描路径。

3. 使用计划强制工具（pg_hint_plan） #

若上述方法无效，可借助pg_hint_plan扩展强制优化器使用指定索引：
先安装扩展：

CREATE EXTENSION pg_hint_plan;

再在查询中加入索引强制提示：

/*+ IndexScan(index_test temp_multiple_idx) */
SELECT * FROM index_test WHERE weekday = 'mo';

此方法直接绕过优化器选择逻辑，适合快速解决问题的场景。

4. 调整RLS策略的参数传递方式 #

若业务允许，改用current_user或角色属性传递school_id（这类值在优化器阶段可确定），例如：

-- 假设每个用户对应唯一school_id，存储在自定义映射表中
CREATE POLICY "separate_schools" ON "index_test"
    USING (school_id = (SELECT school_id FROM user_school_mapping WHERE username = current_user));

如果user_school_mapping表数据稳定，优化器能更好评估过滤条件的选择性，从而利用索引前缀。

内容的提问来源于stack exchange，提问作者Tobias Marschall