MySQL触发器禁止在触发器中对原表或命名相近的影子表执行INSERT/UPDATE，否则报ERROR 1442；须确保影子表独立存在、无外键依赖，并用AFTER触发器配合OLD/NEW显式字段插入完整快照。
触发器里不能直接 INSERT INTO 原表的影子表？先确认权限和命名冲突
MySQL 触发器执行时，对当前表（即触发该触发器的表）的写操作会报错 ERROR 1442 (HY000): Can't update table 't' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。这不是语法问题，而是 MySQL 的硬性限制：不能在 AFTER INSERT 触发器里再 INSERT 到同一张表（哪怕目标是影子表），如果影子表名和原表名太接近（比如 t_shadow vs t），某些版本还会因元数据锁误判为“同一张表”。
所以第一步必须确保：影子表独立存在、无外键依赖原表、且不在同一事务上下文中被隐式关联。
INSERT 和 UPDATE 触发器要分开写，且 UPDATE 需用 OLD/NEW 区分字段值
一个触发器只能响应一种事件类型，INSERT 和 UPDATE 必须拆成两个触发器；UPDATE 场景下，必须显式用 OLD.column_name 和 NEW.column_name 来获取变更前后的值，否则无法记录“改了什么”。常见错误是直接写 column_name，结果取到的是 NEW 值，丢失原始状态。
-
BEFORE INSERT触发器里不能读NEW.id（如果 id 是自增主键，此时还未生成） -
AFTER UPDATE才能安全写入影子表，因为此时OLD和NEW都已确定 - 如果只关心某几个字段变更（如只记
status变化），应在触发器里加IF OLD.status != NEW.status THEN ... END IF;
影子表结构要包含操作类型、时间戳、操作人（如有）、完整行快照
单纯复制原表结构不够——缺少上下文信息。建议影子表至少包含：op_type ENUM('INSERT', 'UPDATE', 'DELETE')、op_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP、op_user VARCHAR(64) DEFAULT USER()（注意 USER() 返回连接用户，不是应用层传的账号）、以及所有原表字段（含主键）。如果原表有 BLOB/TEXT 字段，影子表也得保留，否则快照不完整。
示例建表语句（假设原表为 orders）：
CREATE TABLE orders_shadow (
shadow_id BIGINT PRIMARY KEY AUTO_INCREMENT,
op_type ENUM('INSERT', 'UPDATE') NOT NULL,
op_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
op_user VARCHAR(64) DEFAULT USER(),
id INT NOT NULL,
order_no VARCHAR(32) NOT NULL,
amount DECIMAL(10,2),
status TINYINT,
created_at DATETIME,
updated_at DATETIME
);
触发器里用 CONCAT 拼接动态 SQL 很危险，优先用静态 INSERT + 显式字段列表
有人想用 CONCAT('INSERT INTO orders_shadow SET ...', NEW.id) 动态拼 SQL，这不仅性能差，还极易引入 SQL 注入（尤其当 NEW 字段含单引号或反斜杠时）。MySQL 触发器不支持 PREPARE/EXECUTE，所以根本没法安全执行动态语句。正确做法是：每个字段都显式列出，值用 NEW.xxx 或 OLD.xxx 直接引用。
例如 AFTER UPDATE 触发器片段：
DELIMITER $$
CREATE TRIGGER orders_after_update
AFTER UPDATE ON orders
FOR EACH ROW
BEGIN
INSERT INTO orders_shadow (
op_type, op_time, op_user,
id, order_no, amount, status, created_at, updated_at
) VALUES (
'UPDATE', NOW(), USER(),
NEW.id, NEW.order_no, NEW.amount, NEW.status, NEW.created_at, NEW.updated_at
);
END$$
DELIMITER ;
真正麻烦的是 DELETE 场景——OLD 可用但没 NEW，而很多业务要求记录“谁删的”“什么时候删的”，这些信息只能靠应用层传入（比如在删除前写入临时表或 session 变量），触发器本身拿不到上下文。这点容易被忽略，上线后才发现删操作日志全是 NULL。
