高并发场景下禁用外键是互联网公司硬性规范，因其触发父表查询与共享间隙锁致写入延迟飙升，ON DELETE CASCADE易引发全表锁定，分库分表后外键失效且不报错，应用层校验更可控、可灰度、可降级。
为什么不能直接在应用层更新冗余字段
因为业务逻辑分散、事务边界不一致、异常路径遗漏，会导致主表和冗余字段长期不一致。比如订单表存了 user_name，但用户改名后只更新了 users 表，订单里的旧名字就滞留了——这不是缓存，是数据污染。
存储过程能绑定到事务内执行，且复用性高。但要注意：它不是银弹，仅适用于「变更频次低 + 依赖关系明确 + 不跨库」的场景。
CREATE PROCEDURE 必须显式处理事务和错误
MySQL 或 PostgreSQL 中，存储过程默认不自动参与调用方事务（尤其 MySQL 的 AUTOCOMMIT=1 下）。若忽略这点，主表更新成功、冗余字段更新失败，就留下脏数据。
实操建议：
- 开头加
DECLARE EXIT HANDLER FOR SQLEXCEPTION（MySQL）或BEGIN ... EXCEPTION WHEN OTHERS THEN（PostgreSQL），确保出错时回滚 - 冗余字段更新必须和主表更新在同一个事务块里，不要拆成两个
CALL - 避免在过程中调用外部 HTTP 或写文件——这会破坏原子性
- 示例（MySQL）：
CREATE PROCEDURE sync_order_user_name(IN p_order_id BIGINT) BEGIN DECLARE EXIT HANDLER FOR SQLEXCEPTION ROLLBACK; START TRANSACTION; UPDATE orders SET user_name = ( SELECT name FROM users WHERE id = orders.user_id ) WHERE id = p_order_id; COMMIT; END
触发器 vs 存储过程：什么情况下该选后者
触发器看似自动，但调试难、堆叠风险高、影响写入性能。而存储过程由业务逻辑主动调用，可控性强。
适合用存储过程同步冗余字段的典型场景：
- 批量修复历史数据（如跑一次
CALL sync_all_orders()） - 多步关联更新（例如：订单状态变「已完成」→ 同时更新
last_updated_by和completed_at） - 需要校验逻辑（比如只在
user_name IS NULL时才补值） - 调用方已开启事务，希望冗余更新成为其子操作（此时用触发器反而会报
Can't update table in stored function/trigger）
参数设计要防 SQL 注入，也要防空值误更新
别把用户输入直接拼进 EXECUTE IMMEDIATE 或动态 SQL；更隐蔽的问题是：传入 NULL 的 p_user_id 可能让 WHERE user_id = NULL 匹配不到任何行，表面成功，实际没生效。
关键检查点：
- 所有输入参数先用
IF p_order_id IS NULL THEN LEAVE proc_label; END IF;拦截 - UPDATE 语句末尾加上
AND user_id IS NOT NULL等防御条件 - 执行后查
ROW_COUNT()（MySQL）或GET DIAGNOSTICS（PG），为 0 时记录告警日志，而不是静默跳过 - 避免用字符串拼接构造表名或字段名——这类需求应通过元数据表+权限控制解决，而非开放动态 SQL
