ON UPDATE CASCADE仅在外键关联的父表主键/唯一键被更新时触发子表外键字段自动更新，依赖InnoDB外键约束，非外键列或直接更新子表操作均无效。
MySQL中ALTER TABLE加ON UPDATE CASCADE的实际效果
直接说结论：ON UPDATE CASCADE 在 MySQL 中**只对外键字段生效，且仅在更新被引用表（父表）的主键/唯一键时触发**；它不会自动同步非外键列、不作用于UPDATE语句中直接修改子表字段的操作。
常见误解是以为给某个字段加了这个属性，后续任意更新都会“级联”，其实它完全依赖外键约束的存在和触发时机。
- 必须先有定义好的外键（
FOREIGN KEY），才能在其上指定ON UPDATE CASCADE - 只有执行类似
UPDATE parent_table SET id = 100 WHERE id = 1这类修改父表主键的操作，才会触发子表对应外键字段的自动更新 - 如果父表主键是自增整数，通常根本不会去改它——所以这个特性在实际业务中使用频率远低于
ON DELETE CASCADE - MyISAM 引擎不支持外键，因此也不支持该选项；必须用 InnoDB
如何安全地为已有外键添加ON UPDATE CASCADE
不能直接用 ALTER TABLE ... MODIFY COLUMN 添加，必须先删外键再重建。这是最容易出错的环节：名字记错、约束没删干净、引擎不一致都会导致失败。
- 先查出当前外键名：
SHOW CREATE TABLE child_table，找类似CONSTRAINT `fk_user_id` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`)的行 - 删掉旧约束：
ALTER TABLE child_table DROP FOREIGN KEY fk_user_id（注意这里写的是约束名，不是列名） - 重建带级联的外键：
ALTER TABLE child_table ADD CONSTRAINT fk_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON UPDATE CASCADE - 确保两张表字符集、排序规则、数据类型完全一致，否则会报错
ERROR 1005 (HY000): Can't create table
PostgreSQL里没有ON UPDATE CASCADE？那怎么替代
PostgreSQL 确实不支持 ON UPDATE CASCADE，但它支持更灵活的触发器机制。比起 MySQL 的隐式行为，PG 要求你显式写出逻辑，反而更容易控制边界。
- 用
CREATE TRIGGER+CREATE FUNCTION组合实现等效行为 - 触发时机选
AFTER UPDATE ON parent_table，条件限制为只在主键列变化时执行：OLD.id IS DISTINCT FROM NEW.id - 注意避免循环触发：如果子表更新又反过来影响父表，得加标记或检查层级
- 性能上比 MySQL 的原生级联略重，但可加索引优化子表
WHERE foreign_key = OLD.id查询
为什么线上环境很少真用ON UPDATE CASCADE
不是技术不行，而是业务上它太“危险”——一次主键变更可能悄无声息地改掉成千上万条子记录，日志难追溯，回滚极困难。
- 绝大多数系统设计时就约定：主键（尤其是代理主键如
id）一旦生成绝不更新 - 真正需要同步的字段（比如用户邮箱、部门编号）应该走应用层逻辑或定期任务，而不是靠数据库级联
- 审计合规场景下，DBA 往往禁用所有
CASCADE行为，防止误操作放大影响 - ORM 框架（如 Django、Rails）默认也不生成带
ON UPDATE CASCADE的迁移，就是出于可控性考虑
真正要用的时候，得确认上游业务已锁定主键不可变、下游所有子表都做好索引、并且有完整备份+回滚预案。不然不如手动写 UPDATE。
