能，但需满足InnoDB引擎、字段类型兼容（如VARBINARY或足够长VARCHAR）、MySQL≥5.7且加密函数可用；密钥须SHA2生成、不可写死或依赖会话变量，NULL值需显式判断。
MySQL的BEFORE INSERT触发器能自动加密敏感字段吗
能，但必须满足几个硬性条件：表引擎为InnoDB、字段类型支持足够长度（如VARCHAR(255)）、MySQL版本≥5.7（推荐8.0+），且加密函数必须在SQL层可用。最常踩的坑是直接在触发器里调用AES_ENCRYPT()却不传密钥或忽略返回值为VARBINARY——这会导致插入失败或数据截断。
典型场景是用户注册时自动加密id_card和phone字段。触发器本身不处理密钥轮换，也不校验明文长度，这些得靠应用层兜底。
-
AES_ENCRYPT()返回VARBINARY，目标字段必须声明为VARBINARY或足够长的VARCHAR（如VARCHAR(512)） - 密钥不能写死在触发器里，建议用
SHA2('your-secret-key', 256)生成固定长度密钥，避免因密钥含特殊字符导致加密失败 - 触发器无法访问会话变量，所以
@key这类变量不可用；密钥必须硬编码或从SELECT查配置表（但会拖慢插入性能） - 如果字段允许NULL，触发器里要显式判断
IF NEW.phone IS NOT NULL THEN ... END IF;，否则AES_ENCRYPT(NULL, key)返回NULL，可能掩盖逻辑错误
PostgreSQL中用BEFORE INSERT触发器加密要注意什么
PostgreSQL没有内置AES函数，得依赖pgcrypto扩展，且触发器函数必须用PL/pgSQL编写。最大误区是以为encrypt()和gen_salt()能直接用在触发器里——其实encrypt()默认用bf（Blowfish），而解密时若没传相同salt参数就会失败。
实际部署中，pgcrypto需管理员权限启用：CREATE EXTENSION IF NOT EXISTS pgcrypto;。未启用就建触发器会报错function encrypt does not exist。
- 加密字段类型必须是
BYTEA，对应应用层读取时需调用decrypt()并传入相同salt（通常存为固定字符串，如'my-salt-2024'） - 触发器函数里不能用
RAISE EXCEPTION拦截空值，否则整个INSERT失败；更稳妥的是用COALESCE(NEW.ssn, '')兜底 - PostgreSQL触发器对大字段（如身份证号）加密后体积膨胀约30%，若原字段是
CHAR(18)，目标字段至少设为BYTEA，别用TEXT存base64结果 - 加密操作消耗CPU，单次INSERT延迟增加0.5–2ms，在高并发写入场景下可能成为瓶颈，建议只对真正敏感字段启用
触发器加密后，应用查询时如何安全解密
触发器只管写入时加密，读取时必须由应用自己调用对应解密函数。MySQL里用AES_DECRYPT()，PostgreSQL里用decrypt()，两者都要求密钥/盐值完全一致。最容易被忽略的是字符集问题：MySQL中AES_DECRYPT()返回VARBINARY，若直接转成UTF8字符串可能乱码，必须显式用CONVERT(... USING utf8mb4)。
- MySQL示例：
SELECT CONVERT(AES_DECRYPT(id_card_enc, SHA2('key',256)) USING utf8mb4) AS id_card FROM users; - PostgreSQL示例：
SELECT convert_from(decrypt(ssn_enc, 'my-salt-2024', 'bf'), 'UTF8') AS ssn FROM users; - 千万别在WHERE子句里对加密字段做
=匹配——加密后相同原文产生不同密文（加了随机IV），只能用于展示，不能用于检索 - 如果业务需要按手机号模糊搜索，得额外维护一个脱敏索引字段（如手机号前3后4），而非尝试解密全量数据
为什么生产环境很少纯靠触发器做敏感字段加密
因为触发器把加密逻辑锁死在数据库层，密钥管理、算法升级、审计日志都难以介入。比如某次安全审计要求改用国密SM4，触发器就得全部重写并停机更新；又或者DBA想记录谁在什么时候加密了哪条数据，触发器没法写入另一张审计表（除非用INSERT INTO audit_log，但这违反自治事务原则，MySQL不支持，PG需用dblink间接实现）。
更现实的做法是：触发器仅作兜底（防应用层绕过），主加密逻辑放在ORM层或API网关，数据库只负责存储密文。这样密钥可从KMS拉取、加解密可打监控埋点、异常能统一捕获——而这些，都是触发器做不到的。
