MariaDB触发器中NEW变量仅反映当前行，多行INSERT时无法通过变量收集全部数据；正确做法是避免逐行处理，改用集合操作、异步解耦或批量导入前禁用触发器。
多行INSERT时NEW变量只保留最后一行值
在MariaDB（和MySQL）中，NEW不是单个记录，而是逻辑上的“当前行”占位符；但触发器对每一行分别执行一次——所以NEW.id每次只代表该次触发的那一行。问题出在有人误用SELECT @id = NEW.id FROM DUAL或类似赋值，以为能遍历所有插入行。实际上，这种写法在多行场景下毫无意义：@id只会被最后触发的那行覆盖，其余行彻底丢失。
常见错误现象：
- 单行插入时日志/统计正常，批量插入后只记录了一条或计数少于实际行数
- 触发器调用存储过程传入
@id，结果只有最后一个id被处理 - UPDATE关联表时仅更新了某一行，其他行没反应
根本原因：MariaDB不提供inserted表（SQL Server术语），也不支持NEW TABLE（PostgreSQL 14+特性）。你面对的是“逐行触发 + 单行上下文”的事实，无法靠变量收集全部数据。
MariaDB里不能用游标替代集合操作
虽然语法上允许在触发器中声明游标并遍历SELECT * FROM some_table WHERE id IN (SELECT id FROM temp_table)这类伪集合，但MariaDB触发器**不支持直接访问inserted或deleted逻辑表**，也没有NEW TABLE或OLD TABLE。所谓“用游标处理多行”，实际得先把数据暂存到临时表或内存表，再查出来——这不仅引入额外I/O和锁，还破坏原子性，且临时表在事务中行为不稳定。
更关键的是：游标在触发器中不可靠。MariaDB不保证游标在并发INSERT下的执行顺序；FETCH可能跳过行或重复取；一旦触发器因锁等待超时中断，游标句柄残留可能导致后续会话报错Cursor is already open。这不是性能问题，是语义错配：触发器本就不是为循环设计的。
正确思路是放弃“逐行处理”幻想，转而问自己：这个逻辑真需要对每行都独立执行吗？
用集合式UPDATE/INSERT代替逐行赋值
90%的触发器需求其实可以改写成单条SQL语句完成，比如审计日志、状态同步、计数更新。核心是利用触发器外层DML已知的上下文，配合JOIN或子查询一次性处理。
例如，有orders表和audit_log表，想记录每笔插入订单：
CREATE TRIGGER after_orders_insert
AFTER INSERT ON orders
FOR EACH ROW
BEGIN
INSERT INTO audit_log (table_name, record_id, action, created_at)
VALUES ('orders', NEW.id, 'insert', NOW());
END;
这段代码本身没错，但它会在1000行插入时执行1000次INSERT。更高效的做法是——别在触发器里做这事。改为应用层批量写日志，或用异步队列（如Kafka + 消费者服务）解耦。如果必须在数据库内闭环，可考虑：
- 触发器只写轻量事件表（如
event_queue），字段仅含table_name、op_type、batch_id；外部定时任务按batch_id聚合处理 - 对统计类需求（如
student_count），直接用AFTER INSERT ... UPDATE students_count SET stu_count = stu_count + (SELECT COUNT(*) FROM orders WHERE inserted_time > LAST_INSERT_TIME)——但这需要时间戳或自增ID锚点，且要加唯一约束防重复计算
MariaDB没有NEW TABLE，也没有MERGE或ON CONFLICT，所以“批量聚合更新”只能靠业务层补全，触发器只适合纯单行副作用（如设置NEW.updated_at = NOW()）。
批量导入前禁用触发器是最简单有效的方案
如果你的场景是ETL、报表导入或初始化数据，根本不需要触发器参与——它们只会拖慢速度、引发死锁、甚至导致Stack depth limit exceeded（递归触发）。
MariaDB支持标准语法：
ALTER TABLE orders DISABLE TRIGGER tg_order_audit; -- 执行大批量 INSERT ... ALTER TABLE orders ENABLE TRIGGER tg_order_audit;
注意点：
-
DISABLE TRIGGER不阻塞DML，不影响约束和索引，也不需要锁表（MariaDB 10.3+） - 禁用后，触发器逻辑完全跳过，但原INSERT仍受事务、外键、唯一约束保护
- 务必在同一个会话中
ENABLE，否则其他连接插入时仍无触发逻辑
比起改写触发器逻辑、加锁、分批、建临时表，禁用/启用是零风险、零学习成本、效果立竿见影的操作。真正难的不是怎么让触发器支持多行，而是意识到：它本就不该处理多行。
