SQLite触发器不能直接UPDATE多张表，只能通过BEGIN...END块内分步执行多个独立UPDATE语句，且需启用PRAGMA recursive_triggers = ON；典型应用是AFTER UPDATE触发器同步更新关联表，如订单状态变更时更新用户最后下单时间和状态统计。
SQLite触发器不能直接UPDATE多张表
SQLite的UPDATE语句本身不支持多表语法（比如UPDATE t1 JOIN t2 ON ... SET t1.x = ..., t2.y = ...），触发器里也不能用这种写法。你写的触发器如果试图在AFTER UPDATE里用一条UPDATE改两张表，会直接报错：near "JOIN": syntax error 或 no such table: t2（如果用了别名但没声明）。触发器里的SQL是单语句上下文，只能逐表操作。
真正可行的路径是：在一个触发器中按顺序执行多个独立的UPDATE语句——但这必须用BEGIN ... END块封装，且仅在启用PRAGMA recursive_triggers = ON的前提下才稳定生效（默认关闭）。
实操建议：
- 确保已开启递归触发器：
PRAGMA recursive_triggers = ON（否则第二个UPDATE可能被忽略） - 所有涉及的表必须已存在，且字段名、类型要严格匹配，触发器不校验跨表约束
- 避免循环触发：比如
t1更新触发t2更新，而t2的触发器又反过来更新t1——这会导致too many levels of trigger recursion错误 - 事务安全：整个触发器逻辑包裹在隐式事务中，任一
UPDATE失败，全部回滚
用AFTER UPDATE触发器分步更新关联表
典型场景：订单表orders更新status时，同步更新用户表users的last_order_time和统计表stats_by_status的计数。不能靠一条SQL，但可以用触发器链式响应。
示例（假设orders有id, user_id, status, created_at）：
CREATE TRIGGER update_user_and_stats_after_order_status AFTER UPDATE OF status ON orders BEGIN UPDATE users SET last_order_time = NEW.created_at WHERE id = NEW.user_id; <p>UPDATE stats_by_status SET count = count + 1 WHERE status = NEW.status;</p><p>UPDATE stats_by_status SET count = count - 1 WHERE status = OLD.status; END;
注意点：
-
NEW和OLD只在当前触发的表（orders）上下文中有效，不能用来引用其他表字段 - 每个
UPDATE必须显式写出WHERE条件，漏写会导致全表误更新 - 如果
stats_by_status中NEW.status对应行不存在，count = count + 1不会插入新行——需额外用INSERT OR IGNORE配合UPDATE或改用INSERT ... ON CONFLICT（SQLite 3.24+）
替代方案：用VIEW + INSTEAD OF触发器模拟“联合更新”
当业务逻辑固定、关联关系明确（如主从一对多），可建一个VIEW把多表字段拼在一起，再用INSTEAD OF UPDATE触发器接管写入逻辑。这不是真联合更新，而是把应用层的“想改两个地方”翻译成触发器里的两步操作。
例如建视图order_summary包含orders.id, users.name, orders.status：
CREATE VIEW order_summary AS SELECT o.id, u.name, o.status FROM orders o JOIN users u ON o.user_id = u.id;
然后定义触发器：
CREATE TRIGGER update_order_summary_instead INSTEAD OF UPDATE ON order_summary BEGIN UPDATE orders SET status = NEW.status WHERE id = NEW.id; -- 注意：这里不能直接改users.name，因为VIEW里name来自JOIN，不是基表可写列 -- 若真要改name，得在VIEW定义里暴露users.id，或另建专用更新接口 END;
关键限制：
-
INSTEAD OF触发器只对VIEW有效，且SQLite要求VIEW必须是简单SELECT（不能含GROUP BY、聚合、子查询等） - VIEW列必须明确来自单个基表字段，否则触发器无法映射到具体
UPDATE目标 - 无法通过VIEW直接更新JOIN结果中的“另一张表”，仍需在触发器里手动
UPDATE第二张表
性能与调试陷阱
多表触发器实际是隐式串行执行，每多一次UPDATE就多一次B-tree查找和日志写入。在高频更新场景下，延迟会明显高于单表操作。
调试时最容易忽略的三点：
- 触发器是否真的被触发？用
PRAGMA trigger_list确认注册状态，用PRAGMA recursive_triggers检查开关 - 触发时机选错：
BEFORE UPDATE里读NEW字段没问题，但改NEW.status只影响当前语句；AFTER才能确保原始变更已落盘 - 外键约束冲突：如果第二张表有
ON UPDATE CASCADE，又写了触发器去主动更新它，可能重复触发或违反约束
复杂业务逻辑别硬塞进触发器——先评估是否更适合由应用层用事务控制多表更新，触发器更适合轻量、确定性高的数据同步。
