SQL不支持原生行级回调，触发器是集合级操作；需在触发器内用条件分支或日志表+外部服务实现分流处理。
SQL 本身不支持“对每一行执行不同回调逻辑”的原生语法——触发器是集合级的，不是行级循环器。 你看到的“逐行处理”，其实是用游标、临时表或 JOIN 模拟出来的，本质仍是单次触发、多行处理。真要每行调不同逻辑，得把判断和分支写进触发器主体里，而不是靠数据库自动分发。
SQL Server 触发器中如何访问 inserted 表的多行数据
SQL Server 的 AFTER UPDATE 触发器只触发一次，但 inserted 和 deleted 是内存中的结果集（不是游标），可直接 JOIN、GROUP BY 或 SUM()。常见错误是写成：
UPDATE t SET col = (SELECT LineTotal FROM inserted) -- 错！子查询返回多行会报错
正确做法是显式关联：
- 用
FROM inserted i INNER JOIN target_table t ON t.id = i.id实现逐行更新 - 若需按条件分流（比如 status=1 调 A 存储过程，status=2 调 B），必须在触发器内用
IF EXISTS (SELECT 1 FROM inserted WHERE status = 1)+INSERT INTO #temp SELECT ... FROM inserted WHERE status = 1分离数据 - 不要在触发器里直接用
EXEC sp_executesql对每一行循环调用——性能极差，且容易死锁
MySQL 中无法在触发器里调用存储过程传入多行数据
MySQL 触发器禁止在 BEFORE/AFTER UPDATE 中对本表做 DML，也禁止在触发器里使用游标或动态 SQL 调用存储过程处理 NEW 的多行（因为 NEW 是单行别名，不支持集合）。所以：
- 所谓“批量更新触发回调”，实际只能靠应用层或定时任务轮询变更日志表
- 如果硬要在数据库侧实现，得先用
INSERT INTO log_table SELECT id, new_status FROM inserted记录变更，再由外部程序消费该日志 -
INSERT ... ON DUPLICATE KEY UPDATE不触发UPDATE触发器里的NEW值判断逻辑——它走的是“插入路径”，ON DUPLICATE部分不算标准 UPDATE，很多字段不可见
用临时表 + 外部程序替代“行级回调”的真实路径
真正可控、可扩展、不卡主业务的方案，是放弃在触发器里做复杂分支，转而用轻量中间层承接：
- 触发器只做一件事：
INSERT INTO change_log (table_name, row_id, old_value, new_value, op_type, created_at) SELECT 'orders', d.id, d.status, i.status, 'UPDATE', GETDATE() FROM inserted i JOIN deleted d ON i.id = d.id WHERE i.status != d.status - 用一个独立服务（Python/Go 脚本）定时拉取
change_log，按row_id查原始数据，再根据业务规则决定调哪个接口、发什么消息、写哪张表 - 这样避免了触发器中嵌套事务、锁等待、超时中断等风险；也能加重试、限流、审计日志
最常被忽略的一点：你以为在触发器里写个 CURSOR 就能“逐行回调”，但 SQL Server 游标默认是 SCROLL + READ_ONLY，且每次 FETCH 都产生额外开销；而 MySQL 根本不支持触发器内声明游标。所谓“行级”，从来不是数据库的默认行为，而是你主动承担的复杂度。
