on update cascade 仅在显式更新被引用的主键或唯一键时生效，且要求被引用列必须是 primary key 或 unique not null；普通索引下该选项被忽略且不报错。
为什么 ON UPDATE CASCADE 在某些字段上根本不起作用
因为外键约束的级联更新只响应 UPDATE 语句中**显式修改了被引用列（如主键或唯一键）** 的操作，而不会响应对关联表中其他字段的更新。更关键的是：MySQL 要求被引用列必须是 PRIMARY KEY 或 UNIQUE NOT NULL；如果只是普通索引，ON UPDATE CASCADE 直接被忽略，且不报错。
常见错误现象：UPDATE users SET name = 'Alice' WHERE id = 1 执行后，orders.user_name 没变——这不是触发器没写好，而是你根本没动 users.id，级联机制压根不会启动。
- 使用场景：仅适用于「变更主键/唯一标识」这种极少见的操作，日常业务中几乎不用
- 参数差异：
ON UPDATE CASCADE和ON UPDATE SET NULL不能共存；一旦定义了后者，前者失效 - 兼容性影响：PostgreSQL 支持
ON UPDATE CASCADE，但 SQLite 只支持ON DELETE CASCADE，不支持更新级联
用 BEFORE UPDATE 触发器同步关联字段是否安全
不安全——除非你严格控制触发器的执行顺序和更新范围。触发器在语句执行前介入，若逻辑中又去 UPDATE 同一张表（比如想补全 updated_at），极易引发“递归触发”或“变异表（mutating table）”错误（Oracle）或死锁（MySQL）。
实操建议：
- 只在
BEFORE UPDATE中修改 当前行的 NEW 字段，不要做跨表UPDATE - 真正需要跨表同步时，改用
AFTER UPDATE+ 显式UPDATE语句，并确保目标表有合适索引（如orders(user_id)） - 避免在触发器里调用存储过程或复杂函数，MySQL 5.7+ 对触发器内事务控制仍较脆弱
示例（安全写法）：
CREATE TRIGGER update_orders_user_name AFTER UPDATE ON users FOR EACH ROW BEGIN UPDATE orders SET user_name = NEW.name WHERE user_id = NEW.id;
触发器补偿失败后怎么快速定位是哪条记录没同步
靠日志查太慢，应该在触发器里加最小化兜底检查。关键是：不要等出问题再查，而是在每次同步后验证影响行数。
实操建议：
- 在
AFTER UPDATE触发器末尾加判断：IF ROW_COUNT() = 0 THEN INSERT INTO sync_log (...) VALUES (...); END IF; - 把
sync_log表设计成带table_name、ref_id、error_msg的轻量结构，避免写入开销过大 - 禁止在触发器里用
SELECT ... INTO去查目标表是否存在匹配行——这会显著拖慢主更新语句，尤其高并发时
为什么不直接用应用层代码处理级联更新
因为应用层写两遍 UPDATE 看似简单，但会破坏原子性：第一个成功、第二个失败时，数据就处于不一致状态。而触发器至少能保证和主语句同事务。
但要注意：触发器不是银弹。它让数据库承担了本该由业务逻辑表达的规则，导致：
- 调试困难：错误堆栈里看不到触发器名，只有
ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger - 迁移成本高：换数据库时，触发器语法（如 MySQL 的
NEW/OLDvs PostgreSQL 的NEW.*）要重写 - 性能隐患：每个触发器都增加语句解析和执行开销，批量更新时尤为明显
真正容易被忽略的点是：很多团队用触发器补历史数据一致性，却忘了禁用 binlog 的 STATEMENT 格式——它会导致从库回放时触发器不执行，主从数据悄然分裂。
