触发器应写在状态变更的源头表上：父表变更驱动子表更新则建在父表，子表聚合反推父表状态则建在子表；必须用after触发器以确保读取事务已生效数据，并建立parent_id与status的联合索引避免全表扫描。
触发器该写在父表还是子表上
父子状态联动的逻辑起点决定触发器位置。如果子表状态变更要影响父表（比如所有子记录 status = 'done' 时父表设为 completed），触发器必须建在子表上；反之，若父表状态变化需批量更新子表（如父表 archived = true 时子表全部置为无效），则触发器建在父表上。常见错误是把“父表改了要同步子表”的逻辑写在子表触发器里——这会导致子表 INSERT/UPDATE 时无意义地重复执行，还可能引发递归或死锁。
- 父表变更驱动子表更新 → 触发器建在
parent_table - 子表聚合状态反推父表状态 → 触发器建在
child_table - 避免跨表写操作嵌套：不要在子表触发器里再 UPDATE 父表的同时，父表触发器又去 UPDATE 子表
用 AFTER 还是 BEFORE 触发器
绝大多数状态联动场景必须用 AFTER 触发器。因为状态计算依赖当前事务已生效的数据，比如判断子表是否全部完成，需要看到本次 INSERT/UPDATE 后的真实行数和值。用 BEFORE 会读不到刚插入的记录，或读到旧值，导致状态误判。
-
AFTER INSERT, UPDATE, DELETE ON child_table是子表聚合类联动的标准选择 -
BEFORE UPDATE ON parent_table只适合做简单校验或字段预处理（如自动填充updated_at），不适合依赖子表数据的逻辑 - PostgreSQL 中
AFTER触发器不能直接访问NEW/OLD的聚合结果，得用子查询或 CTE 显式查表
避免触发器里的 SELECT COUNT(*) 全表扫描
常见写法是 SELECT COUNT(*) FROM child_table WHERE parent_id = NEW.id AND status != 'done' 判断是否全部完成，但没加索引时会拖慢整个事务。真正影响性能的是缺失 parent_id, status 联合索引，而不是触发器本身。
- 必须建立复合索引：
CREATE INDEX idx_child_parent_status ON child_table (parent_id, status) - 别用
NOT IN或!= 'done'做存在性判断，改用EXISTS或COUNT(*) = 0更易走索引 - MySQL 8.0+ 和 PostgreSQL 支持在触发器中调用函数，可把状态计算逻辑封装成
is_parent_completed(parent_id)函数，便于复用和测试
事务边界与并发更新风险
触发器代码运行在主 DML 语句的同一事务中，所以父表状态更新失败会导致整个子表 INSERT 失败——这有时是期望行为（强一致性），但更多时候会掩盖真实业务错误。更大的坑是并发：两个事务同时更新同一批子记录，可能都读到“尚未全部完成”，然后都把父表设为“进行中”，漏掉最终完成状态。
- 对父表状态做条件更新：
UPDATE parent_table SET status = 'completed' WHERE id = NEW.parent_id AND status != 'completed' - 避免在触发器里执行耗时操作（如发消息、调外部 API），会阻塞事务
- 高并发场景下，更稳妥的方式是用定时任务或监听 WAL 日志异步修正状态，而不是全压在触发器里
触发器不是银弹，它把业务逻辑藏在数据库层，调试困难、难以覆盖测试，且不同数据库语法差异大。真要保证父子状态严格一致，优先考虑应用层事务 + 补偿机制，触发器只作为兜底或低频场景的辅助手段。
