不能直接用触发器实现动态复杂数据遮盖，因其仅响应DML事件、不负责遮盖；Oracle的Data Masking由Data Masking and Subsetting Pack提供，而动态查询遮盖应使用VPD+DBMS_REDACT。
不能直接用触发器实现“动态的复杂数据遮盖”——这是常见误解，也是最容易踩坑的地方。 触发器本身不负责遮盖（masking），它只能在 DML 事件发生时执行逻辑；而 Oracle 的 Data Masking 功能由 Data Masking and Subsetting Pack 提供，与触发器无关。混淆这两者会导致权限错误、性能崩溃或审计失败。
为什么触发器不适合做生产级数据遮盖
触发器是运行在事务上下文中的 PL/SQL 块，每次 INSERT/UPDATE 都会同步执行。若你在 BEFORE INSERT 里调用复杂脱敏函数（比如 AES 加密、正则替换、字段打乱），会带来三个硬伤：
- 事务阻塞：脱敏逻辑卡住写入，高并发下锁等待飙升
- 权限陷阱：触发器内调用 UDF 或 Java 存储过程需显式
GRANT EXECUTE，且不能通过角色继承 - 语义错位：遮盖应发生在“数据导出/克隆”阶段，而非“原始写入”阶段——否则业务系统读不到明文，根本无法使用
真正该用触发器的场景：只限于审计日志脱敏
如果你需要在 AFTER UPDATE 时把敏感字段（如身份证号）的明文转成哈希后存进日志表，这是可行的，但必须满足：
- 仅对
:OLD.id_card或:NEW.phone做单向处理（如STANDARD_HASH(:OLD.id_card, 'SHA256')），不反向还原 - 目标表（如
audit_log）字段类型设为RAW(32)或VARCHAR2(64)，避免字符集转换错误 - 禁用
SELECT权限给应用用户，防止从日志表反查原始值
示例片段：
CREATE OR REPLACE TRIGGER trg_masked_audit
AFTER UPDATE ON customer_info
FOR EACH ROW
BEGIN
INSERT INTO audit_log (log_id, cust_id, masked_idcard, op_time)
VALUES (audit_seq.NEXTVAL, :NEW.cust_id,
STANDARD_HASH(:OLD.id_card, 'SHA256'), SYSTIMESTAMP);
END;Oracle 官方推荐的动态遮盖路径：不是触发器，而是 VPD + DBMS_REDACT
若你真需要“查询时动态遮盖”（比如开发人员连库看到的是 *** 而非真实手机号），正确做法是：
- 用
DBMS_REDACT.ADD_POLICY创建列级遮盖策略，指定FUNCTION_TYPE => DBMS_REDACT.PARTIAL和FUNCTION_PARAMETERS => 'VVVVV#VVVVV#VVVVV' - 配合 Virtual Private Database（VPD）策略，按
USER或SESSION_CONTEXT控制是否启用遮盖 - 所有遮盖动作在 SQL 执行引擎层完成，不走触发器、不增加事务开销
关键命令示例：
BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema => 'APP',
object_name => 'customer_info',
policy_name => 'redact_phone_policy',
column_name => 'phone',
function_type => DBMS_REDACT.PARTIAL,
function_parameters => 'VVVVV#VVVVV#VVVVV'
);
END;最易被忽略的一点：遮盖策略默认对 SELECT 生效，但对 INSERT/UPDATE 不生效——这意味着你仍需在应用层或存储过程中确保写入的是合规明文，而不是把遮盖逻辑塞进触发器里去“二次加工”。
