mysql触发器无法将单行订单明细展开为多行插入，因before/after insert触发器仅响应单次dml事件，new只读且不支持循环、多条insert或动态扩行。
MySQL 触发器不能拆分明细行，别往这个方向试
MySQL 的 BEFORE INSERT 或 AFTER INSERT 触发器无法把一行订单明细（比如 order_id=1001, product='TV', quantity=3）自动“展开”成三行插入。触发器里不能执行多条 INSERT、不能循环、不能动态生成行数——它只响应单次 DML 事件，且 NEW 是只读的，改不了，也扩不了。
常见误操作包括：
- 在触发器里写
WHILE @i → MySQL 不支持循环语句（除非嵌套存储过程，但触发器内调用存储过程又受限） - 试图用
INSERT INTO ... SELECT ... FROM JSON_TABLE(...)拆行 → 触发器上下文不支持 JSON_TABLE 或 CTE - 用
SET @sql = CONCAT(...); PREPARE stmt FROM @sql; EXECUTE stmt;→ 触发器禁止 PREPARE/EXECUTE（报错 ERROR 1356）
SQL Server 可以用 AFTER INSERT + CROSS APPLY 拆行，但必须绕过触发器限制
SQL Server 的触发器本身也不直接支持“拆行”，但它允许在触发器中执行完整 T-SQL，包括 CROSS APPLY 和递归逻辑。关键是：不能对原表做 INSERT，而是把 inserted 视为临时结果集，再用集合操作展开。
例如订单明细表 order_items 插入一条 quantity=5 记录，想拆成 5 行：
CREATE TRIGGER trg_split_order_item
ON order_items
AFTER INSERT
AS
BEGIN
INSERT INTO order_items_split (order_id, product, quantity_per_line)
SELECT i.order_id, i.product, 1
FROM inserted i
CROSS APPLY (
SELECT TOP (i.quantity) 1 AS n
FROM master.dbo.spt_values
) t;
END;
注意点：
-
master.dbo.spt_values是常用伪数字表，但行数有限（通常 2500+），quantity超过时得换sys.all_objects或自建数字表 - 目标表
order_items_split必须提前建好，字段类型与逻辑一致 - 触发器内不能修改
inserted，所以原始order_items表仍存总量行；拆分是“额外写入”，不是替换 - 事务一致性：若拆分 INSERT 失败，整个事务回滚——这点容易漏查，日志里要盯住
inserted和目标表是否同步
真正可靠的拆分动作必须放在应用层或存储过程中
所有数据库引擎对触发器的能力约束都指向同一个结论：复杂行变换（尤其是数量驱动的拆行）不该由触发器承担。它既不可控、难调试，又破坏事务语义边界。
推荐做法是把拆分逻辑前移到业务代码或存储过程里：
- 应用层收到
{order_id: 1001, product: 'TV', quantity: 7}后，自行构造 7 条 INSERT 语句批量提交 - 用存储过程封装：输入单行，内部用
WHILE或CTE + RECURSION生成多行，再统一 INSERT —— 这样可加日志、校验、重试 - 如果必须走触发器路由，至少让触发器只做“转发”，把原始行写入中间暂存表，再由后台作业异步拆分并清理，避免阻塞主事务
硬要触发器里强拆，最后往往变成查不出数据、主键冲突、或者某天 quantity 突然超限导致静默截断——这些都不是配置问题，是能力边界卡死的结果。
PostgreSQL 可用 FOR EACH ROW + RETURNING 实现轻量拆分，但仍有隐性成本
PostgreSQL 的触发器支持 RETURNING 和更灵活的 PL/pgSQL 控制结构，理论上能实现单行转多行：
CREATE OR REPLACE FUNCTION split_order_item()
RETURNS TRIGGER AS $$
DECLARE
i INTEGER;
BEGIN
FOR i IN 1..NEW.quantity LOOP
INSERT INTO order_items_split (order_id, product, seq)
VALUES (NEW.order_id, NEW.product, i);
END LOOP;
RETURN NULL; -- 阻止原 INSERT 写入主表（需搭配 INSTEAD OF 触发器）
END;
$$ LANGUAGE plpgsql;
但关键限制是：
- 必须用
INSTEAD OF触发器（只能建在视图上），而 MySQL 不支持这种触发器类型 - 循环插入性能差：
quantity=1000就执行 1000 次 INSERT，锁竞争剧烈 - 无法利用批量 INSERT 的优化，每行都是独立事务开销
- 错误处理脆弱：第 999 行失败，前 998 行已写入，无法原子回滚
所以即使 PostgreSQL 允许语法通过，生产环境也应避免在触发器里做这种操作。拆分逻辑的复杂度和可靠性，永远比表结构迁移更值得前置投入。
