触发器支持“写即同步”但受限于MySQL硬性规则：禁止修改自身表、跨库需显式权限、子查询必须单值返回；仅BEFORE中可赋值NEW，AFTER中跨库须用LIMIT 1标量子查询；INSERT IGNORE/REPLACE不触发触发器；高并发或跨库场景应优先选用应用层双写或定时任务。
触发器能实现“写即同步”，但必须避开 MySQL 的硬性限制：不能在触发器里更新自己、跨库需显式权限、子查询必须单值返回。它适合低频写入、强一致性要求的场景，不适合高并发或复杂关联。
BEFORE UPDATE 中只能改 NEW，不能碰原表
MySQL 5.7+ 明确禁止在触发器中对触发它的那张表执行任何 DML。比如你在 t1 上建了 AFTER UPDATE 触发器，里面写 UPDATE t1 SET x = 1，会直接报错：Can't update table 't1' in stored function/trigger...。
唯一安全的修改方式是通过 NEW.xxx 赋值：
-
SET NEW.updated_at = NOW();—— 合法，影响即将写入的行 -
SET NEW.status = 'pending';—— 合法，覆盖应用层传入值 -
UPDATE t1 SET counter = counter + 1 WHERE id = NEW.id;—— 非法，哪怕加了WHERE也不行
AFTER UPDATE 中跨库同步必须用标量子查询
触发器里不支持 UPDATE t2 JOIN t1 ON ... 这类语法，会报错（错误信息常误导为“子查询不支持 LIMIT”）。正确做法是把关联逻辑收进括号，确保返回单值：
SET NEW.sync_status = ( SELECT IF(t2.is_valid = 1, 'ok', 'error') FROM config t2 WHERE t2.key_name = NEW.config_key LIMIT 1 );
注意几个硬性要求：
- 子查询必须带
LIMIT 1，否则多行返回直接中断触发器 - 外键或唯一索引要建好，不能靠
LIMIT掩盖数据模型缺陷 - 该子查询每行都执行一次，高并发写入时容易成性能瓶颈
- 若没命中（返回
NULL），NEW.sync_status就是NULL，得提前设默认值
INSERT IGNORE / REPLACE 不触发触发器
这是最容易被忽略的坑：INSERT IGNORE 和 REPLACE INTO 对于因唯一键冲突而跳过的行，**完全不会执行任何触发器**——BEFORE INSERT 和 AFTER INSERT 都不走。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
后果很实际：
- 你指望靠触发器同步冗余字段？跳过的那几行就永远不同步
- 想记录插入日志？日志表里压根没这条记录
-
REPLACE实际是先DELETE再INSERT，只触发BEFORE DELETE和BEFORE INSERT，中间状态已丢失
稳妥方案只有两个：
- 统一用
INSERT ... ON DUPLICATE KEY UPDATE，它一定触发BEFORE INSERT - 业务层兜底校验，避免依赖触发器做关键同步
跨库同步前必须确认权限和字符集
触发器内访问其他库的表，不是语法通就完事。常见失败点：
-
ERROR 1142 (42000): SELECT command denied或INSERT command denied：执行账号缺目标库表的SELECT/INSERT权限 - 字符集不一致导致隐式转换失败，例如源表
utf8mb4、目标表latin1，写入中文时可能截断或报错 - 目标表有
NOT NULL字段但没在INSERT中提供值，触发器会直接中断
建议在触发器开头加简单检查：
IF NEW.id IS NULL THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'id cannot be null'; END IF;
真正难的不是写触发器，而是让所有边界条件（空值、类型、权限、并发）都在可控范围内。一旦涉及跨库或高频写入，优先考虑 INSERT INTO ... SELECT 定时任务或应用层双写，别把一致性押在触发器上。
