MySQL触发器中禁止使用COMMIT/ROLLBACK，因其运行在主事务上下文中；工单生成应作为事务一部分，靠唯一索引保障幂等性，跨库、函数调用及高并发场景需规避。
触发器里不能用事务控制语句 COMMIT / ROLLBACK
MySQL 的 AFTER INSERT 触发器运行在插入语句的事务上下文中，它本身不开启新事务，也不能显式提交或回滚。如果你在触发器里写了 COMMIT，会直接报错 ERROR 1422: Explicit or implicit commit is not allowed in stored function or trigger。这是最容易踩的坑——尤其当开发者想“确保工单一定生成”而强行加事务时。
正确做法是：把工单生成逻辑当作原插入事务的一部分。只要主表插入成功，触发器里的 INSERT 就一起提交；一旦触发器内 SQL 报错（比如外键不匹配、字段超长），整个事务会自动回滚，保持数据一致性。
- 避免在触发器中调用含
COMMIT的存储过程 - 不要用
START TRANSACTION或SET autocommit = 0 - 若需异步处理（如调用外部 API），必须改用应用层监听 + 消息队列，不能塞进触发器
INSERT INTO ... SELECT 需严格对齐字段类型和数量
生成关联工单通常要从新插入的记录中提取字段，拼成工单表的一行。用 INSERT INTO ticket (...) SELECT ... FROM DUAL 或直接基于 NEW 引用是最常见写法，但字段顺序、类型、是否允许 NULL 必须完全匹配目标表定义，否则触发器创建失败或运行时报错 ERROR 1136: Column count doesn't match value count 或 ERROR 1265: Data truncated for column。
示例（MySQL）：
CREATE TRIGGER gen_ticket_after_order_insert
AFTER INSERT ON `order`
FOR EACH ROW
INSERT INTO ticket (order_id, title, status, created_at)
VALUES (NEW.id, CONCAT('工单-', NEW.id), 'pending', NOW());
-
NEW.id必须存在且类型兼容ticket.order_id（比如都是BIGINT UNSIGNED） -
CONCAT()返回的是字符串，要确保ticket.title是VARCHAR类型，长度足够 - 如果
ticket.created_at是NOT NULL DEFAULT CURRENT_TIMESTAMP，可省略该字段，但显式写上更可控
跨库写入或调用函数可能触发 SUPER 权限限制
MySQL 默认禁止触发器中执行某些操作，比如向另一个数据库的表写入、调用含 SQL SECURITY DEFINER 的函数、或访问系统表。错误信息通常是 ERROR 1419: You do not have the SUPER privilege...。这不是权限没给够，而是 MySQL 为防止触发器引发不可控副作用做的硬性限制。
解决路径很明确：
- 所有关联表必须与触发器所在表在同一个数据库（schema）下
- 避免在触发器中调用自定义函数，除非该函数声明为
SQL SECURITY INVOKER且不含写操作 - 如果工单需带用户姓名，而用户信息在
auth_user表中，别在触发器里JOIN查询——应提前在应用层查好传入，或改用应用层补全
高并发下自增 ID 冲突或重复生成工单的风险
触发器看似“自动”，但它依赖 NEW 中的值。如果主表用的是 AUTO_INCREMENT，在极短时间窗口内（比如批量导入、多线程插入），NEW.id 是确定的；但若主表用 UUID 或业务生成 ID，且应用层未保证唯一性，就可能出现两条记录 NEW.id 相同，导致工单重复插入并违反唯一约束。
更隐蔽的问题是：触发器无法感知“同一订单是否已被处理过”。比如重试机制导致同一条 INSERT 被执行两次（虽然罕见，但在 binlog 复制或某些 ORM 场景下可能发生），就会生成两个工单。
- 务必在
ticket表上建唯一索引，例如UNIQUE KEY uk_order_id (order_id) - 不要依赖触发器做幂等性保障，应在应用层通过防重 Token 或状态机判断
- 测试时用
INSERT ... SELECT批量插入 1000 行，观察是否全部触发、有无丢漏
触发器不是银弹。它适合强一致性、低频、逻辑简单的关联写入；一旦涉及跨服务、异步通知、复杂校验，就得让位给应用层事件驱动。
