如何监控SQL敏感字段变动_通过触发器实现字段变更日志

MySQL触发器中，BEFORE UPDATE用OLD/NEW取值，禁止查表或更新同表；敏感字段需显式比对并处理NULL；日志表主键用自增ID，字段统一TEXT，须覆盖INSERT/UPDATE/DELETE三类操作，且注意权限与性能。触发器里怎么拿到旧值和新值MySQL 的 BEFORE UPDATE 和 AFTER UPDATE 触发器中，OLD.字段名 和 NEW.字段名 是唯一合法访问方式。不能用变量赋值再比较，也不能查表回读——那会引发递归或死锁。常见错误是写成 SELECT old_value INTO @old FROM ...，这不仅多余，还可能因隔离级别导致读到脏数据；更严重的是，在 BEFORE 触发器里尝试 UPDATE 同一张表，直接报错 Can't update table 't' in stored function/trigger。只在 BEFORE UPDATE 里做字段比对（性能好、逻辑清晰）敏感字段必须显式列出，别用 * 或动态拼接——DDL 变更时触发器不会自动更新如果字段允许 NULL，比较时务必用 IS NULL / IS NOT NULL，别用 = NULL日志表设计要避开主键冲突和字符截断日志表不是越宽越好。字段变动记录的核心是：谁改的、改了哪条、改前改后是什么、什么时候改的。多存冗余字段（比如重复用户姓名）反而增加维护成本和同步风险。典型翻车点：TEXT 字段被截成 VARCHAR(255) 导致敏感内容丢失；或者把 user_id 设为 PRIMARY KEY，结果同一用户多次修改同一条记录就写不进去。主键推荐组合：(id BIGINT AUTO_INCREMENT PRIMARY KEY)，别依赖业务字段原字段值统一用 TEXT 类型存，避免长度限制（尤其 JSON、地址、备注类）加 updated_by 字段，但别直接存用户名——应存登录账号或 token ID，方便溯源且不随人名变更失效INSERT/DELETE 也要覆盖，否则日志链断裂只监听 UPDATE 是最常见疏漏。用户删掉一条含身份证号的记录，或新增一条带银行卡号的记录，这两类操作同样属于敏感字段变动，但不会触发 UPDATE 触发器。 唱鸭 音乐创作全流程的AI自动作曲工具，集 AI 辅助作词、AI 自动作曲、编曲、混音于一体