本文主要介紹了PolarDB資料庫代理（Proxy）提供的動態脫敏功能。
前提條件
PolarDB資料庫代理版本需為2.4.12或以上。如何查看和升級當前資料庫代理版本，請參見小版本升級。
脫敏方案
在資料庫使用中，需要即時地從生產環境中的資料庫（即生產庫）擷取最新的客戶資料來進行報表產生、資料分析、開發測試等。但為了不泄露真實的客戶個人資訊（Personal Identifiable Information），需要將這些資料進行脫敏處理後才能提供給第三方使用。目前脫敏方案包括動態脫敏和靜態脫敏兩種，PolarDB資料庫代理使用的是動態脫敏方案。
脫敏方案 | 說明 | 優點 | 缺點 |
動態脫敏 | 當應用程式發起資料查詢請求時，系統會在資料庫內部對敏感性資料進行變換後再返回給應用程式。 開始查詢前，僅需指定需要進行脫敏查詢的資料庫帳號，以及需要脫敏的資料庫、表或列的名稱即可。 |
| 由於需要對即時資料進行脫敏，因此相較於鏡像庫，生產庫的查詢效能會略受影響。 |
靜態脫敏 | 將生產庫的全量資料匯入至一個鏡像資料庫中，同時在導資料的過程中對敏感性資料進行加密或脫敏。 | 應用程式訪問的不是真正的生產庫而是鏡像庫，因此脫敏過程完全不會影響正常業務對生產庫的使用。 |
|
工作原理
在PolarDB控制台上設定完脫敏規則後，控制台會將規則寫入至Proxy中。當應用程式通過規則中指定的帳號串連至資料庫並查詢規則中指定的列時，Proxy會先將資料庫返回的資料脫敏轉換，再將脫敏後的資料返回給用戶端。
上圖的脫敏規則為：
僅當使用
testAcc帳號串連資料庫進行查詢時生效。僅對查詢結果中
name和age列的資料進行脫敏。
只要查詢結果中包含脫敏列，該列的值都會被脫敏。如SELECT * FROM t1，如果t1表中包含name和age列，則查詢結果中的這2列值會被脫敏。
當應用程式使用testAcc串連資料庫，並查詢某個表中的name、age和hobby時，Proxy會將name和age列的資料進行脫敏後再返回，hobby列的資料則未進行脫敏原樣返回。
Proxy會對不同類型的資料進行不同的脫敏處理，具體脫敏處理說明如下表所示。
資料類型 | 脫敏處理說明 | 樣本 |
整數型（TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT） | Proxy會根據該資料的類型選擇一個符合該類型定義的隨機值。 |
|
小數型（DECIMAL、FLOAT、DOUBLE） |
| |
時間型（DATE、TIME、DATETIME、TIMESTAMP、YEAR） |
| |
除上述3種類型之外的資料 | Proxy會統一使用星號（*）進行替換 |
|
注意事項
動態脫敏功能僅對叢集地址（包括預設叢集地址和自訂叢集地址）生效，使用主地址串連資料庫進行查詢時，動態脫敏功能不生效。查看叢集串連地址的操作步驟，請參見查看串連地址和連接埠。
查詢資料時，若查詢結果中包含需要脫敏的列，且單行資料超過16 MB時，執行該查詢命令的串連會斷開。
例如，若已有一張包含了
name和description列的表person，其中name列需要脫敏，且description列中的資料超過了16 MB。當執行SELECT name, description FROM person時，執行該查詢命令的串連則會斷開。若需要脫敏的資料列作為函數入參，脫敏功能會失效。
例如，已建立了一條需要對
name列資料進行脫敏的規則，當執行SELECT CONCAT(name, '') FROM person進行查詢時， 應用程式仍然能夠讀取到name的原始值。若需要脫敏的資料列同時被用於UNION中，脫敏功能可能會失效。
脫敏失效樣本：已建立了一條需要對
name列資料進行脫敏的規則，當執行SELECT hobby FROM person UNION SELECT name FROM person語句進行查詢時， 應用程式仍然能夠讀取到name的原始值。
使用方法
詳情請參見管理脫敏規則。
附錄：效能影響
脫敏功能會在以下3種情境中對叢集的效能產生影響。
本文使用了叢集的唯讀QPS值進行對比。
情境說明 | 效能影響 | |
帳號是否加入脫敏規則 | 查詢是否命中規則 | |
否 | 否 | 此時等同於當前帳號未使用脫敏功能，效能沒有損耗。 |
是 | 否 | 此時Proxy僅會分析結果集中的列定義資料，不會對真正的查詢結果（即行資料）進行脫敏。 效能損耗約為6%（即開啟脫敏功能前後的唯讀QPS值相差約6%）。 |
是 | 此時Proxy不僅會分析結果集中的列定義資料，還會對真正的查詢結果（即行資料）進行脫敏。 此時效能損耗與結果集大小相關，結果行數越多損耗越大。 在返回單行結果的情況下，效能損耗約為6%。 | |