不能用触发器实现“自动脱敏显示”，因为触发器不响应SELECT操作，仅在INSERT/UPDATE/DELETE时执行；MySQL、PostgreSQL和SQL Server均不支持SELECT触发器，试图创建会直接报错；真正可行的查询脱敏方案是视图结合确定性表达式与严格权限隔离。
不能用触发器实现“自动脱敏显示”——触发器不响应 SELECT，根本不会在查询时执行。
MySQL / PostgreSQL / SQL Server 都不支持 SELECT 触发器
常见错误现象：CREATE TRIGGER INSTEAD OF SELECT ON users 或 BEFORE SELECT 会直接报错，比如 MySQL 的 ERROR 1419、SQL Server 的 Incorrect syntax near 'SELECT'。触发器只在 INSERT、UPDATE、DELETE 时触发，SELECT 是纯读操作，数据库引擎压根不走触发器路径。
为什么有人误以为触发器能做“查询脱敏”？
混淆了两个完全不同的动作：
- 写入时清洗（如
BEFORE INSERT把手机号存成138****5678）→ 触发器可以做，但原始值永久丢失 - 查询时动态遮掩（如查出来是
138****5678，但表里仍是13812345678）→ 触发器做不到，必须靠视图或应用层
把脱敏逻辑塞进写入触发器，结果所有下游系统（包括从库、BI 工具、风控服务）拿到的都是掩码值，审计回溯、实名核验、反欺诈比对全部失效。
真正可行的查询脱敏方案：视图 + 确定性表达式
核心原则：脱敏逻辑必须出现在 SELECT 列表中，且不能依赖非确定性函数（如 NOW()、RAND()），否则视图创建失败或主从复制异常。
- 手机号脱敏：
CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))（注意先COALESCE(phone, '')防 NULL） - 身份证号脱敏：
CONCAT(LEFT(id_card, 6), REPEAT('*', 8), RIGHT(id_card, 4)) - 按角色差异化：用
CASE WHEN CURRENT_ROLE() IN ('app_reader') THEN ... ELSE id_card END，但需确认数据库支持运行时角色判断（PostgreSQL 支持，MySQL 8.0+ 需配合USER()或自定义函数） - 权限隔离：撤销用户对原表的
SELECT权限，只授予视图权限 —— 否则视图形同虚设
容易被忽略的硬约束
视图中所有脱敏表达式必须是确定性的；MySQL 要求 CREATE VIEW 不能含 NOW()、UUID() 等；PostgreSQL 在 SECURITY DEFINER 视图中若调用非 STABLE 函数，可能引发权限越界；SQL Server 的列级动态脱敏（MASKED WITH）只能定义在表结构上，不能在视图里“调用”。这些限制不是配置问题，而是引擎设计决定的——想绕开，只会让脱敏变成不可维护的黑盒。
