ROW LEVEL SECURITY(RLS) 性能问题

最新推荐文章于 2025-07-07 13:49:48 发布

原创最新推荐文章于 2025-07-07 13:49:48 发布 · 5.4k 阅读

1 ·

CC 4.0 BY-SA版权

SQL TUNING 专栏收录该内容

91 篇文章

订阅专栏

本文讨论了一个ROW LEVEL SECURITY (RLS) 性能问题，在一个系统中，不同用户类别的权限策略导致数据查询效率低下。通过调整SQL查询并使用特定提示（hint），成功解决了性能瓶颈。

记得之前在HP 的时候，遇到一个ROW LEVEL SECURITY 的性能问题，当时也在CSDN发了一个博客，不过因为涉及用户信息泄密，所以把博客删除了。最近一个网友也遇到RLS性能问题

……petma 19:58:06
我现在遇到一个比较郁闷的问题
……petma 19:59:23
是这样的，我们的系统，将用户分为了几类，每一类的权限策略是不一样的，然后数据查询的时候，我们先要调安全的方法，得到一个权限策略的SQL，然后再将这个SQL做为参数，传到真正的数据查询中
……petma 19:59:31
可是，加了这个SQL后，就非常慢
落落 19:59:53
ROW LEVEL SECURITY?
……petma 20:00:05
是的
落落 20:00:47
哈哈哈我之前遇到过
落落 20:00:52
你在外企？
落落 20:01:03
这个好办
落落 20:01:11
你把 RLS 的限制条件发一下给我看看
落落 20:01:20
是不是限制条件是一个子查询？
……petma 20:01:24
是
……petma 20:01:37
SELECT *
FROM (SELECT A.*, ROWNUM RN
FROM (
select b.* from os_form_base b,ttwo_wo_info t
where

t.form_id=b.form_id
and site_code in (
select resCode from (select * from(select dept_code as resCode,dept_name as resName from sec_dept) WHERE 1!=1 OR ((1=1 and resCode in('0001030102','0001030105','000103010501','00010301050101','000103010502','00010301050201','000103010503','00010301050301','000103010504','00010301050401','000103010505','00010301050501','000103010506','00010301050601','000103010507','00010301050701','000103010508','00010301050801','000103010509','00010301050901','000103010510','00010301051001','000103010511','00010301051101','000103010512','00010301051201','000103010514','0001030109','000103010901','00010301090101','000103010902','00010301090201','000103010903','00010301090301','000103010904','00010301090401','000103010905','00010301090501','000103010906','00010301090601','000103010907','00010301090701','000103010908','000103010909','000103010910','000103010911','00010301091101','00010301091102','00010301091103','00010301091104','000103011906','00010301190601','000103011907','00010301190701') ) or (1!=1)) and resCode like '00010301%'))

order by t.form_id desc

) A
WHERE ROWNUM <= 15
) WHERE RN > 0
……petma 20:01:56
这段用于权限控制
……petma 20:02:49
我也用PL/SQL F5看了下，把权限控制里的1!=1这种去掉后，里面的耗费减少了，但是查询时间没变化
落落 20:03:03
SQL优化不要去看cost
落落 20:03:10
也不要用PL/SQL 去看执行计划
……petma 20:03:12
哦
落落 20:03:23
你在限制条件里面加一个 HINT
落落 20:03:31
/*+ no_unnest */
落落 20:03:33
试一试
……petma 20:03:45
这个我不会加，呆会去百度，加了这个之后呢
落落 20:03:57
加了再试一试
落落 20:04:02
不行再找我
……petma 20:04:07
OK，QQQ
落落 20:04:12
直接就在 SELECT 后面加上即可
落落 20:04:34
限制条件里面的 SELECT 后面加
落落 20:04:46
而不是在最开始的 SELECT 那里加小心点哈
……petma 20:05:44
where site_code in (select res_code 这里面加哈)
落落 20:07:50
where site_code in (select /*+ no_unnest */ res_code 这里面加哈)

落落 20:07:52
嗯
……petma 20:09:10
为什么一下子就非常快了
……petma 20:13:28
膜拜
落落 20:15:05