Compliance in Databases: A Study of Structural Policies and Query Optimization

當企業在資料庫中導入符合資料隱私規範的內容層級存取控制時，標準的成本基礎最佳化器面對多層疊加的安全策略，往往會產出效能極差的執行計畫，甚至導致系統停擺。一項針對 PostgreSQL 的最新實證研究指出，若是採用白箱查詢重寫技術，雖能大幅提升複雜查詢的執行效率，卻會使查詢規劃的運算成本激增 2 至 4 倍。這項數據揭示了現代資料庫引擎在存取安全性與查詢最佳化之間，仍存在難以跨越的架構斷層。

內容層級存取控制與 PostgreSQL 最佳化器的盲區

現代資料隱私法規（如 GDPR、HIPAA 與 CCPA）以及企業內部治理需求，正驅動資料管理系統向更細緻的存取控制邁進。有別於傳統基於角色或身分的權限控管，內容層級存取控制（Content-based Access Control）要求系統必須根據查詢所涉及的「資料內容」來決定存取權限。例如，特定供應商的紀錄僅在該供應商位於核准區域時才可見；或者一筆訂單必須達到特定的優先等級才能被讀取。

目前主流的關聯式資料庫引擎已原生支援此類機制。以開源領域最具代表性的 PostgreSQL 為例，其透過資料列層級安全性（RLS，Row-Level Security）讓管理者能在資料表上附加過濾述詞，並在每次查詢時自動注入這些條件。商用系統如 SQL Server、Oracle（透過 VPD 技術）以及 Snowflake 也具備類似功能。原生執行的優勢在於策略只需定義一次即可透明化應用，且無法被應用程式端的程式碼繞過。

然而，儘管這項技術被廣泛採用，其對效能的深層影響卻鮮少被探討。單一的等值條件或範圍過濾，通常能輕易被查詢最佳化器（Optimizer）吸收而無明顯延遲。但在真實的商業治理場景中，安全策略往往具備高度的組合性（Compositional）：針對 lineitem 表的策略可能依賴於 partsupp 的策略，而後者又受到 supplier 表策略的限制。當這些跨表的階層依賴不斷累積，注入的述詞結構複雜度將急遽上升。現有的成本基礎最佳化器並非為了同時處理原始查詢與龐大策略子查詢而設計，導致其在面對合規約束時，多數情況下會產出極度缺乏效率的執行計畫。

遮罩函數與五大原子策略的 SQL 語法定義

為了解決此一系統性缺陷，研究團隊捨棄了單純依賴 LLM（大型語言模型）生成測試策略的作法，因為未經約束的 LLM 產出往往侷限於狹隘的範圍，或是產生帶有致命循環引用的 SQL，這在基礎執行環境中根本無法運作。取而代之的是，研究人員構建了一套嚴謹的結構化政策模型與具備表達能力的上下文無關文法（Context-free Grammar）。

在該框架中，一個基礎政策單元由遮罩函數（Masking Function）、資料列可見性（Tuple Visibility）以及屬性呈現（Attribute Presentation）所構成。當系統判定某筆資料不符合檢視權限時，並非只能粗暴地隱藏該列，遮罩函數可以將特定欄位的值轉換為 Null（即抑制顯示），或進行匿名化處理。基於這套邏輯，框架進一步定義了五種原子政策（Atomic Policy）結構：包含基於屬性閾值的「屬性述詞」、具備半連接（Semi-join）語意的「存在性述詞」、確保無違規關聯的「通用述詞」（對應 Anti-join）、基於群組統計的「聚合述詞」（利用 GROUP BY 與 HAVING），以及涉及高階聚合計算的「統計述詞」。

透過邏輯運算子（AND、OR、NOT）與條件表達式（IF-THEN-ELSE），這些原子政策可以無限重組。例如，當邏輯 OR 被套用在兩個政策時，只要資料列滿足任一述詞即可完全顯示；只有在兩者皆不滿足時，雙重的遮罩機制才會同時作用於該資料列。這種文法確保了每一條複雜的商業規則都能被轉換為標準的抽象語法樹（AST），從而向查詢最佳化器揭露其語法結構，為後續的述詞下推（Predicate Pushdown）與冗餘消除鋪平道路。

TPC-H 測試基準下的白箱與黑箱政策生成

政策的執行機制在資料庫設計中被劃分為「白箱」與「黑箱」兩大陣營，這取決於最佳化器是否能看見並拆解這些政策邏輯。在白箱機制中（包含標準 RLS、查詢重寫與透明視圖），政策述詞對最佳化器完全開放，這帶來了聯合最佳化的可能，但也同時擴大了潛在的旁路推論攻擊面。反之，黑箱機制（例如 PostgreSQL 中的 SECURITY DEFINER 使用者定義函數或不透明視圖）則將政策邏輯徹底封裝，雖然犧牲了效能，卻能防堵資訊外洩，更是處理「循環依賴政策」的唯一解方。

為了進行系統化的效能評估，研究團隊將上述框架導入標準的 TPC-H 分析型基準測試中，建立具備商業語意的複合型合規負載（Scale Factor 1 與 10）。在無循環依賴（Acyclic）的設定下，他們採用嚴格的層級指派演算法，確保政策的參考對象僅限於底層的基礎資料表，藉此避免無限迴圈。針對客戶、供應商與訂單明細，分別設定了包含財務信用、跨國交易與庫存水位的過濾條件。

另一方面，針對那些需要雙向存取規則或相互可見性限制的應用場景，團隊也生成了不受限的「循環政策」（Cyclic Policies）。例如，某項政策可能限制只能顯示「未與異常大量訂單關聯的零件」，而該訂單的檢視邏輯又反過來關聯零件表。這類政策如果強行寫入一般的 RLS，會在編譯階段直接觸發 PostgreSQL 的無限遞迴錯誤，因此必須依賴黑箱機制的隔離才能安全執行。

白箱最佳化實測：LITHE 重寫計畫引發的運算代價

在白箱環境下的實測數據，揭示了不同執行策略在效能與資源消耗上的激烈拉扯。研究團隊在配備 128GB 記憶體與雙 Intel Xeon 處理器的環境下，比較了純 RLS、安全視圖（Secure Views）以及透過先進重寫器 LITHE 進行的「查詢重寫」（Query Rewrite）。

從執行時間來看，查詢重寫技術幾乎在所有複雜查詢中都徹底擊敗了原生的純 RLS。由於 LITHE 將政策述詞直接內聯（Inline）至使用者查詢中，並透過代數簡化重組邏輯，最佳化器得以做出更精準的連接排序（Join-ordering）。這種優勢在包含關聯性政策述詞的密集連接查詢（如 Q3、Q7、Q9、Q19）中尤為明顯，純 RLS 在這些場景下完全錯失了跨述詞最佳化的機會。

然而，天下沒有白吃的午餐。將政策徹底展開攤平的代價，是查詢規劃時間（Optimization Time）的瘋狂飆升。實測顯示，安全視圖與查詢重寫的規劃開銷通常是純 RLS 的 2 到 4 倍。更嚴峻的是，在處理 Q8 與 Q21 這類觸發多層疊加政策的極端查詢時，查詢重寫會因為產生的查詢樹過度龐大，直接超出規劃器的運算極限而導致「超時失敗」。這證明了白箱方法的兩難：追求極致的執行效能，必然伴隨著難以預期的規劃資源消耗。

黑箱隔離與循環依賴：索引 RLS 展現的效能韌性

當場景切換到出於安全考量或因應循環依賴而必須關閉跨界最佳化的「黑箱環境」時，系統的效能瓶頸發生了根本性的轉移。在這種設定下，PostgreSQL 的引擎無法遞迴展開政策述詞，因此得以安全度過循環政策的編譯階段，但隨之而來的是執行效率的雪崩。

實測數據明確指出，純 RLS（黑箱模式）在執行階段承受了毀滅性的開銷，特別是在同時觸發多重政策的查詢中。以 Q8（同時啟動四項政策）以及 Q5、Q7、Q9（各自啟動三項政策）為例，執行時間出現了數倍的延遲。更致命的是，純 RLS 在面對 Q2 與 Q5 時直接發生了執行超時。這顯示當最佳化器被蒙上眼睛時，政策的組合深度成為了拖垮系統的主因。

此時，政策感知索引（Indexed RLS） 發揮了關鍵的救援作用。雖然在白箱無循環場景中，建立索引的幫助微乎其微，但在黑箱與循環政策的摧殘下，針對政策查詢欄位建立專屬索引，不僅大幅壓低了最差情況下的執行延遲，更成功讓原本超時的 Q2 與 Q5 順利完賽。對比同樣具備黑箱隔離特性的「安全屏障視圖（Security Barrier Views）」，具備索引的黑箱 RLS 展現了更穩定的執行韌性與較低的規劃開銷，成為處理這類無限制結構政策的最佳實務選擇。

資料庫安全策略的結構複雜度直接決定了效能瓶頸，未來的查詢最佳化器必須將存取控制視為一等公民，而非單純的附加條件。