从适用于MySQL 8.0.17的 Percona Server 开始，Percona Server附带了数据屏蔽插件，使用与MySQL Enterprise Masking and De-identification功能相同的API。该插件由Francisco Miguel Biete开发，并作为社区贡献提交给Percona Server。
什么是数据屏蔽？
上面提到的数据屏蔽插件提供了易于使用的方法来隐藏敏感数据，例如社会保险号：
mysql> SELECT ssn, mask_ssn(ssn) FROM employees WHERE id = 1337;
+-------------+---------------+
| ssn | mask_ssn(ssn) |
+-------------+---------------+
| 935-20-5725 | XXX-XX-5725 |
+-------------+---------------+
1 row in set (0.00 sec)
甚至将字典中包含的单词列入黑名单，用随机选择的替换词替换它们：
mysql> SELECT city, gen_blacklist(city, 'US_Cities', 'DE_Cities') FROM employees WHERE id = 1337;
+----------+-----------------------------------------------+
| city | gen_blacklist(city, 'US_Cities', 'DE_Cities') |
+----------+-----------------------------------------------+
| Houston | Berlin |
+----------+-----------------------------------------------+
1 row in set (0.00 sec)
mysql> SELECT city, gen_blacklist(city, 'US_Cities', 'DE_Cities') FROM employees WHERE id = 1337;
+----------+-----------------------------------------------+
| city | gen_blacklist(city, 'US_Cities', 'DE_Cities') |
+----------+-----------------------------------------------+
| Houston | Essen |
+----------+-----------------------------------------------+
1 row in set (0.00 sec)
性能
使用此类插件之前的一个重要问题是其成本：与其他方法相比，它又如何？由于目标是向用户隐藏一些数据，因此该方法可能是：
- 完全不屏蔽SQL端，并在使用数据库的程序中完全实现它
- 直接在视图/查询中使用现有功能和用户功能来获得相似的结果
- 将被屏蔽的列或被屏蔽的表添加到数据库
1和3中的selects的运行时性能大致相同：对于1，屏蔽性能移至客户端程序，而不是SQL Server。对于3，它发生在插入期间。两者都具有额外的成本，因为（1）需要更改（所有）客户端程序，并且（3）大大增加了空间需求。
第二个选项仅对某些功能才是现实的：例如，上面的SSN掩码可以使用正确的子字符串和串联实现。
遮罩功能
插件提供的大多数功能都执行简单的字符串替换，例如，在给定位置屏蔽SSN，信用卡号或仅是子字符串的函数。它们具有相同的性能特征，例如，我们可以看到使用不同的SSN屏蔽方案运行sysbench测试的以下数字：
实作 每秒查询
SELECT ssn（未屏蔽） 2503
选择mask_ssn（ssn） 2287
SELECT CONCAT（“ XXX-XX-”，RIGHT（ssn，4）） 2303
如下表所示，mask_ssn和手动字符串操作具有相似的性能，而如果加载了插件，则掩码功能将更易于使用和维护。
替换功能
但是，某些函数对字符串列表进行操作，例如已经提到的gen_blacklist。这些列表在8.0.17和8.0.18中使用线性复杂度算法，因此最适合小型词典。从8.0.19开始，该算法更改为对数复杂度搜索，但代价是增加了字典加载成本。由于字典通常在服务器运行期间加载一次，但使用了很多次，因此使用较大的字典可以减少执行时间。
使用对数搜索时间，某些字典大小的性能如下表所示：
字典大小 每秒查询
0（不列入黑名单） 2506
10 2063
100 1885年
200 1863年
500 1731
1000 1558
1000（100匹配） 1875年
请注意，虽然搜索本身的复杂度是对数的，但查询都在同一数据集上运行：一百万条记录，每条记录都是从5000个条目的字典中随机选择的。在表中的大多数行中，不仅字典的大小更大，而且黑名单函数还会找到更多匹配项，从而导致越来越多的字符串替换。由于字典中的所有项目均来自用于生成列的字典，因此最小的10项字典仅替换了结果的0.2％，而大小为1000的字典则达到了20％。因为这是现实的，所以以这种方式保持测试–更大的字典通常会导致更多匹配。
同样，最后一个条目展示了一个字典，其中实际表中仅存在10％的记录，显示了相对于其他1000个条目表的搜索性能。
