ON UPDATE CASCADE仅在InnoDB中对外键引用的父表主键/唯一键更新时触发子表外键字段自动更新，不支持非主键字段变更的业务级级联，后者需用触发器或应用层实现。
MySQL 中没有 ON UPDATE CASCADE 对 FOREIGN KEY 的完整支持？
MySQL 的 InnoDB 引擎确实支持 ON UPDATE CASCADE，但仅限于更新被引用的主键（如 parent_id）时，自动更新外键列。它**不支持**“父记录某字段更新后，自动更新所有子记录对应字段”的业务级级联——比如修改部门名称后，让所有下属员工的 dept_name 字段同步变更。这种需求必须靠应用层或触发器实现，不能依赖 DDL 约束。
用触发器实现父表字段更新 → 子表字段自动同步
这是最贴近“级联更新”语义的可控方案。注意：触发器只在父表执行 UPDATE 时生效，且需明确指定影响范围，避免误更新。
常见错误现象：Can't update table 'parent' in stored function/trigger —— 这是因为在 BEFORE UPDATE 触发器里又去改了父表本身；必须用 AFTER UPDATE，且只更新子表。
实操建议：
- 触发器类型选
AFTER UPDATE，确保父表已稳定提交 - 只对真正发生变化的字段做判断，例如：
IF OLD.dept_name != NEW.dept_name THEN ... - 更新子表时加
WHERE parent_id = OLD.id，防止全表扫描或误匹配 - 如果子表数据量大，考虑在
parent_id上建索引
CREATE TRIGGER update_child_dept_name
AFTER UPDATE ON departments
FOR EACH ROW
BEGIN
IF OLD.dept_name != NEW.dept_name THEN
UPDATE employees SET dept_name = NEW.dept_name WHERE parent_id = OLD.id;
END IF;
END;
应用层批量更新比触发器更可控？
当需要跨多个子表、带条件过滤、或涉及复杂逻辑（如只更新“在职”子记录）时，触发器反而难维护。此时在应用代码中显式执行两步更新更清晰。
CAD通信网关公共库（装修设计扩展版）。提供统一CAD COM封装接口，支持AutoCAD/天正双模式，包含装修专业图层体系、材料图块、房间边界检测、弧形吊顶COM接口。复用建筑施工图方案Skill0公共库。
使用场景：
- 更新父记录后，需同时更新子表多个字段（不止一个）
- 子表更新需关联其他表做校验（如检查预算是否超限）
- 事务一致性要求高，且需捕获部分子记录失败的情况
关键点：
- 必须用同一事务包裹父表和子表的
UPDATE，否则可能产生数据不一致 - 避免在循环中逐条更新子记录，改用单条
UPDATE ... JOIN或批量IN查询 - 注意 MySQL 的
safe_updates模式可能拒绝无WHERE条件的更新，开发环境要关掉或显式加LIMIT
UPDATE employees e JOIN departments d ON e.parent_id = d.id SET e.dept_name = d.dept_name WHERE d.id = 123;
PostgreSQL 用户别漏掉 DEFERRABLE 和规则系统
PostgreSQL 不支持 ON UPDATE CASCADE 用于非主键字段，但提供更灵活的替代方案：可延迟的外键 + CREATE RULE，或直接用 WITH RECURSIVE 配合 UPDATE 实现树形结构的深度级联（如组织架构中“修改CEO姓名，同步到所有下级岗位头衔”）。
容易踩的坑：
-
CREATE RULE在 PostgreSQL 12+ 已标记为“过时”，官方推荐用触发器替代 -
WITH RECURSIVE做级联更新时，若树太深，可能触发max_recursive_depth限制 - 规则（RULE）对
UPDATE的重写行为隐式性强，调试困难，生产环境慎用
复杂点始终在于：SQL 本身不定义“业务级级联”的语义，你得自己说清“哪些字段变、影响哪些子行、是否穿透多层”。没通用解，只有按场景选触发器、应用逻辑或存储过程。
