存储过程无法替代RLS实现真正的行级安全控制，因其需显式调用、无法拦截直连查询或ORM操作，且易被绕过；RLS则在查询计划阶段自动注入过滤条件，覆盖SELECT/UPDATE/DELETE全操作。
不能在存储过程中“实现”真正的行级安全控制——它只能模拟，且极易被绕过。 存储过程不是 RLS 的替代方案，而是应用层补救手段。SQL Server、PostgreSQL、MySQL 的原生 RLS 都作用于 SELECT/UPDATE 等语句执行前的查询计划阶段，而存储过程需要显式调用，ORM 或直连查询根本不会走它。
为什么存储过程无法替代 RLS
常见误解是“把 WHERE 条件写进存储过程里就安全了”。但问题在于：
- 业务代码发的是
SELECT * FROM orders，不是EXEC get_my_orders—— 这条语句完全绕过过程 - 用户只要拥有原表
SELECT权限，就能直接查表，过程形同虚设 - DBA 或高权限账号调用过程时，若未严格限制上下文（如
CURRENT_USER()），可能返回越权数据 - 过程内部无法拦截外部对基表的 DML 操作，
UPDATE orders SET status='shipped'仍可批量改写他人数据
SQL Server 中用存储过程“模拟”行过滤的实操陷阱
如果必须用过程（比如兼容老版本 SQL Server 2014 及以下），关键不是“怎么写”，而是“怎么防绕过”：
- 必须
REVOKE SELECT ON dbo.orders FROM PUBLIC，只给过程执行权限：GRANT EXECUTE ON get_my_orders TO [app_user] - 过程内必须用确定性上下文函数，避免
SESSION_CONTEXT(N'userid')未设置时出错；推荐搭配SET CONTEXT_INFO初始化（需应用层配合） - 禁止在过程里拼接 SQL 字符串，否则引入注入风险；所有过滤条件必须硬编码或通过参数化输入（如
@user_id INT） - 不能依赖
ORIGINAL_LOGIN()或SUSER_SNAME()—— 它们返回连接登录名，不是应用认证的用户，中间件复用连接时会错乱
PostgreSQL/MySQL 下更危险：视图比存储过程还可靠一点
MySQL 5.7 / PostgreSQL 9.4+ 虽不支持原生 RLS（MySQL 8.0.22+ 才有 CREATE ROW POLICY），但视图至少能透明拦截查询：
- MySQL 视图示例：
CREATE VIEW my_tasks AS SELECT * FROM tasks WHERE owner = SUBSTRING_INDEX(USER(), '@', 1)，再REVOKE SELECT ON tasks FROM 'alice'@'%'; GRANT SELECT ON my_tasks TO 'alice'@'%' - PostgreSQL 可结合
current_setting('app.user_id', true)，但必须确保应用每次连接都执行SET app.user_id = '123'，否则策略失效 - 存储过程在这两个系统里更弱：MySQL 的过程无法返回结果集供
SELECT * FROM ...直接消费；PostgreSQL 的过程（FUNCTION）虽可返回SETOF，但仍需显式SELECT * FROM my_func()，无法透明覆盖基表访问
真正容易被忽略的一点：RLS 策略函数里的列引用必须是**基表真实列名**，不能是计算列或表达式别名；一旦表结构变更（比如重命名 sales_rep 列），SQL Server 的 SCHEMABINDING 会直接报错，而存储过程却悄无声息地返回空结果或全量数据——这种静默失败最危险。
