update join仅适用于一次性批量订正，不支持实时同步；必须显式指定目标表、用select预验证关联逻辑、where精确过滤，且mysql触发器中禁止跨表join更新。
不能靠单条 UPDATE JOIN 一劳永逸地“修复”冗余字段不一致——它只适合一次性校准，不是同步机制。真正在业务中跑着的系统，必须区分「批量订正」和「实时同步」两种场景，否则越修越乱。
用 UPDATE JOIN 批量订正历史数据
这是最直接、最可控的兜底手段，适用于上线后发现冗余字段已大面积失真，或迁移旧数据时补全字段。
-
UPDATE必须显式写出被更新表名，不能只写别名；JOIN要放在UPDATE关键字之后，不是FROM - 务必先用
SELECT验证关联逻辑：比如SELECT o.id, o.product_name, p.name FROM orders o JOIN products p ON o.product_id = p.id WHERE o.product_name != p.name - WHERE 条件要精确限定范围，避免误更新；例如加
AND o.product_name IS NULL OR o.product_name != p.name - MySQL 不支持
UPDATE t1 SET ... FROM t1 JOIN t2，写了就报ERROR 1064；PostgreSQL 则必须用UPDATE ... FROM ...语法
BEFORE 触发器只能改 NEW，不能跨表写原表
想在用户改 products.name 的同时自动刷到 orders.product_name？别在 BEFORE UPDATE 里写 UPDATE orders ——MySQL 5.7+ 明确禁止，会报 Can't update table 'orders' in stored function/trigger because it is already used by statement。
-
BEFORE UPDATE唯一合法操作是赋值给NEW.xxx，比如SET NEW.updated_at = NOW() - 真正跨表更新必须挪到
AFTER UPDATE，且只能通过NEW.id或子查询驱动，不能JOIN更新（语法不支持，会报错） - 记得加空值判断：
IF NOT (NEW.name OLD.name) THEN ...，否则NULL比较会失效 - 高并发下对同一张
orders表频繁UPDATE，容易推高innodb_row_lock_time_avg
AFTER 触发器跨表更新必须用标量子查询
触发器里不允许 UPDATE t2 JOIN t1，也不允许子查询带 LIMIT（会被误判为“不支持 LIMIT 的子查询”）。唯一安全写法是把关联逻辑收进括号，强制返回单值。
- 错误写法：
UPDATE orders SET product_name = (SELECT name FROM products p WHERE p.id = NEW.id LIMIT 1)——LIMIT在触发器中不被允许 - 正确写法：
UPDATE orders SET product_name = (SELECT name FROM products WHERE id = NEW.id)，前提是products.id是主键或有唯一约束 - 如果被关联字段可能为
NULL，用COALESCE((SELECT name FROM ...), OLD.product_name)防止覆盖有效值 - 所有
AFTER更新都应在目标表上建好索引，否则每次触发都扫全表，写入延迟飙升
INSERT IGNORE 和 REPLACE INTO 不触发触发器
这是最容易被忽略的盲区：批量导入、ORM 的 bulk_create、甚至 INSERT IGNORE，默认都不走触发器。你以为加了触发器就万事大吉，结果数据早从后门进来了。
-
LOAD DATA INFILE、INSERT INTO ... VALUES (), ()、REPLACE INTO全部跳过触发器 - 想覆盖这个行为，只能拆成单行事务 + 显式
CALL存储过程，或改用应用层异步任务兜底 - Supabase 的
on_auth_user_created钩子、PostgreSQL 的pg_notify、MySQL 9.6+ 的BINLOG变更流，才是更可靠的同步入口 - 别依赖触发器做强一致性保障——它只适合低频、简单、可预判的同步；高频变更必须移出数据库层
真正难的不是写那几行 SQL，而是判断哪部分该在数据库里做，哪部分该交给应用层或消息队列；一旦选错边界，后续的锁争用、主从延迟、binlog 膨胀都会接踵而至。
