补全存量数据不能只靠触发器，因其仅对新增或更新数据生效，无法处理历史数据；必须用UPDATE JOIN等批量修正方式，再用触发器保障后续增量一致性。
补全存量数据时为什么不能只靠触发器
触发器只对新插入或更新的数据生效，对历史数据完全无感。INSERT、UPDATE 触发器不会自动回扫表里已有的百万行记录。想靠它“初始化”补全，等于指望门铃响了才去修十年前漏水的水管——根本不是它的职责范围。
常见错误现象：BEFORE INSERT 触发器里写了关联查询补 user_name，结果跑完发现老用户记录的 user_name 全是 NULL，新插入的才对。这就是混淆了“实时约束”和“批量修复”两个场景。
- 触发器适合做数据一致性兜底（比如防止插入非法
user_id） - 补全存量必须用
UPDATE ... JOIN或子查询一次性修正 - 若业务要求后续新增/修改也同步补全，才需叠加触发器作为第二道保障
用 UPDATE JOIN 一次性补全关联字段（MySQL / PostgreSQL）
这是最直接、可控、可验证的方式。核心是把主表和关联表通过外键字段拼起来，再把目标字段写回去。
假设订单表 orders 缺少 customer_name，而客户信息在 customers 表中：
UPDATE orders o JOIN customers c ON o.customer_id = c.id SET o.customer_name = c.name WHERE o.customer_name IS NULL;
注意点：
-
WHERE条件一定要加，否则会无差别覆盖所有行（包括已补全的），可能引发误更新 - PostgreSQL 语法略有不同，需用
FROM：UPDATE orders SET customer_name = c.name FROM customers c WHERE orders.customer_id = c.id AND orders.customer_name IS NULL - 大表执行前先
EXPLAIN确认customer_id有索引，否则可能锁表几分钟
触发器只负责“增量保活”，不是初始化工具
补全完存量后，再建触发器来守住后续变更。但要注意：触发器逻辑必须轻量、确定、无副作用。
典型反例：BEFORE INSERT 触发器里调用存储过程查远程 API 补字段——这会让插入变慢、失败风险高、事务不可控。
- 推荐只做简单内联查询：
SELECT name INTO NEW.customer_name FROM customers WHERE id = NEW.customer_id - 务必处理
NOT FOUND情况（如设为NULL或抛自定义异常），避免静默失败 - MySQL 中若关联表没索引，触发器内
SELECT可能成为性能瓶颈；PostgreSQL 的AFTER INSERT不支持直接改NEW，得用BEFORE
更稳妥的初始化方案：脚本 + 事务 + 校验
线上补数据不是执行一条 SQL 就完事。真实场景要考虑回滚、分批、核对。
- 用
BEGIN; ... UPDATE ...; SELECT COUNT(*) FROM orders WHERE customer_name IS NULL;包裹操作，出错可ROLLBACK - 千万级表别一次性更新，加
LIMIT 10000分批（MySQL 支持，PostgreSQL 需用ctid或游标） - 补完后必做校验：
SELECT COUNT(*) FROM orders o LEFT JOIN customers c ON o.customer_id = c.id WHERE o.customer_name IS NOT NULL AND (c.name IS NULL OR o.customer_name != c.name) - 如果关联表本身也有缺失（比如
customer_id是脏数据），先清理外键再补全，否则越补越乱
真正麻烦的从来不是语法，而是你不知道那条 customer_id = 999999 在 customers 表里压根不存在。补全前，先确认关联关系是否干净。
