權限系統數據庫設計：RBAC 中間表 vs JSON 字段存儲深度對比

在業務系統權限模塊設計中，傳統 RBAC（基於角色的訪問控制）通過角色-模塊-操作三張表加多對多中間表實現細粒度授權。隨著業務增長，中間表數據量激增，登錄時多表關聯查詢成為性能瓶頸。有架構師提出將權限直接序列化為 JSON 存入角色表單字段，以空間換時間。兩種方案各有優劣，需結合業務規模、變更頻率、查詢模式綜合評估。

方案一：標準化關聯表（傳統 RBAC）

結構示例

role (id, name)
module (id, code, name)
operation (id, module_id, code, name)
role_permission (role_id, module_id, operation_id) -- 中間表

優點

• 規範性強：符合第三範式，數據一致性有外鍵約束保障。
• 靈活查詢：支持任意維度的權限檢索、審計、報表分析。
• 變更友好：增減模塊/操作只需操作元數據表，無需批量更新角色記錄。

缺點

• 查詢開銷大：登錄驗權需 Join 4-5 張表，高併發下易成瓶頸。
• 中間表膨脹：角色數 × 模塊數 × 操作數，萬級角色下記錄易達百萬級。

方案二：JSON 字段扁平化存儲

結構示例

role (id, name, permissions JSON)
-- permissions 範例：
{"modules": [{"code": "user", "operations": ["read","write"]}, {"code": "order", "operations": ["read"]}]}

優點

• 讀取極快：單表查詢，無 Join，登錄延遲可降至亞毫秒級。
• 結構靈活：無需遷移 Schema 即可新增自定義權限屬性（如數據範圍、字段級權限）。

缺點

• 寫入放大：模塊/操作變更需遍歷所有角色逐條反序列化、修改、序列化、更新，易發生鎖爭用。
• 查詢受限：難以高效支持「查擁有某操作的所有角色」等反向檢索，需全表掃描或引入 GIN 索引（PG） / 虛擬列（MySQL 8.0+）。
• 一致性風險：應用層需自行保證 JSON 結構合法性，缺乏數據庫級約束。

決策建議

最佳實踐：核心權限元數據（模塊/操作定義）仍用關聯表維護，運行時權限樹構建緩存至 Redis，登錄時直接讀取緩存。既保留了結構化優勢，又消除了實時 Join 開銷。若團隊缺乏緩存運維能力，MySQL 8.0 的虛擬列 + JSON 索引或 PostgreSQL 的 JSONB + GIN 索引也是可行的折中方案。