能，仅限BEFORE INSERT或BEFORE UPDATE中修改NEW字段值，AFTER中无效；须确保类型兼容、避免隐式转换，且不可在触发器内UPDATE本表以防递归。
触发器里不能直接修改 NEW 的字段值？
MySQL 触发器（BEFORE INSERT 或 BEFORE UPDATE）中，NEW 是可写的，但仅限于当前触发的表字段；你确实可以给 NEW.id_card 赋新值——这是脱敏的关键前提。很多人误以为 NEW 只读，结果写完没生效，其实是赋值语句写错了位置或类型不匹配。
实操要点：
-
BEFORE INSERT和BEFORE UPDATE都能改NEW.id_card，AFTER类型触发器则完全无效 - 字段类型必须兼容：如果原字段是
VARCHAR(18)，脱敏后仍是字符串，没问题；但如果误写成NEW.id_card := 123（整数），会触发隐式转换或报错Truncated incorrect DOUBLE value - 别在触发器里调用存储函数处理脱敏逻辑——除非该函数被声明为
DETERMINISTIC且有SQL SECURITY DEFINER，否则可能在二进制日志（binlog）中导致主从不一致
身份证脱敏逻辑怎么写才安全又合规？
常见错误是只做简单掩码，比如 CONCAT(LEFT(id_card, 6), '****', RIGHT(id_card, 4))，这在 MySQL 5.7+ 会因 sql_mode 含 STRICT_TRANS_TABLES 报错：如果 id_card 为空或长度不足 18，RIGHT(id_card, 4) 返回空，拼接后变成 ******，但字段非空约束或业务校验可能崩。
稳妥做法：
- 先判断长度和格式：
IF CHAR_LENGTH(NEW.id_card) = 18 AND NEW.id_card REGEXP '^[0-9]{17}[0-9Xx]$' THEN - 再分段脱敏：
NEW.id_card := CONCAT(LEFT(NEW.id_card, 6), '********', RIGHT(NEW.id_card, 4)) - 对非法值统一设为
NULL或固定占位符（如'INVALID_IDCARD'），避免脏数据入库 - 不要用
REPLACE或正则替换——MySQL 原生REGEXP_REPLACE在 8.0.4+ 才支持，低版本只能靠字符串函数硬写
触发器会影响 INSERT/UPDATE 性能吗？
影响存在，但通常可控。单行插入时，一次触发器执行开销约 0.02–0.05ms（SSD + 中等配置），瓶颈不在逻辑本身，而在两点：
- 触发器内用了子查询（比如查字典表判断地区码）→ 立刻变慢，且可能死锁
- 表上有多个触发器（尤其跨表操作）→ 执行顺序难维护，binlog 写入延迟上升
- 高并发写入场景下，触发器逻辑若含锁表操作（如误写
SELECT ... FOR UPDATE），会放大锁等待
建议始终把脱敏逻辑控制在纯字符串计算内，不查表、不调过程、不写日志。
为什么 INSERT IGNORE / REPLACE INTO 下脱敏失效？
这是最容易踩的坑。INSERT IGNORE 和 REPLACE INTO 在遇到唯一键冲突时行为不同，但共同点是：它们仍会触发 BEFORE INSERT —— 所以脱敏本该生效。失效的真实原因通常是：
-
REPLACE INTO实际执行的是「DELETE + INSERT」，旧记录删了，新记录走BEFORE INSERT，脱敏正常；但如果原表有ON DELETE CASCADE外键，级联删除可能触发其他触发器干扰流程 - 更常见的是字段映射问题：比如你写了
INSERT IGNORE INTO user (name, id_card) VALUES ('张三', '110101199001011234')，但触发器监听的是user_info表，表名写错导致根本没触发 - 权限问题：触发器由定义者（
DEFINER）权限执行，如果定义者账号被回收或密码过期，触发器静默失败，SHOW WARNINGS也看不到提示
上线前务必用 INSERT IGNORE 和 REPLACE INTO 各跑一条真实数据，再查表确认 id_card 字段是否已脱敏——别只测普通 INSERT。
