MySQL触发器无法限制单次批量插入行数，因NEW仅指向当前行且无inserted表；只能逐行校验，总量限制须在应用层、存储过程或代理层实现。
批量插入时触发器只执行一次，但inserted表含多行
MySQL 的 BEFORE INSERT 触发器对批量语句（如 INSERT INTO t VALUES (1),(2),(3)）只触发一次，但 NEW 并不指向单行——它每次只反映**当前被处理的那一行**。也就是说，触发器逻辑会为每一行重复执行，不是“一次查总数、统一拦住”。常见误解是以为能用一个 COUNT(*) 拦下整批，实际做不到。
真正要限制“单次批量最多插 N 行”，必须在应用层或存储过程里控制 VALUES 列表长度；触发器层面只能做**逐行校验**，无法感知“这次 INSERT 一共来了几条”。
- SQL Server 的
inserted表在批量插入中会包含所有新行，可直接SELECT COUNT(*) FROM inserted判断批次大小 - MySQL 没有等价的
inserted表，NEW是标量，无法统计本次批量行数 - PostgreSQL 的
NEW同样是单行记录，需配合FOR EACH STATEMENT触发器（但该类型不支持NEW/OLD）
MySQL 中想拦住超量批量插入，得靠应用层预判或拆分
因为 MySQL 触发器无法获取本次 INSERT 的总行数，硬要在数据库端实现“单次最多插 100 行”，只能放弃触发器，改用以下方式：
- 应用层拼 SQL 前检查
VALUES子句项数，超限则报错或自动分批 - 用存储过程封装插入逻辑：
CREATE PROCEDURE insert_batch(IN vals TEXT, IN max_rows INT)，内部解析并校验 - 禁用原生批量语法，强制走 PREPARE + EXECUTE 循环，每行单独触发
- 如果必须用触发器兜底，只能退而求其次：限制**单用户单日总量**或**全表硬上限**，而非“单次操作行数”
试图在触发器里用 SELECT COUNT(*) FROM information_schema.PROCESSLIST 或会话变量模拟批次计数，既不可靠又违反事务隔离原则。
SIGNAL 必须在每行触发时独立判断，否则漏拦
即使你接受“逐行限制”，也得注意：若在触发器里只查一次总数、然后用变量缓存结果，后续行会复用旧值，导致漏判。正确做法是每行都重新查、重新比。
例如限制单用户当日最多提交 5 条：
DELIMITER $$
CREATE TRIGGER limit_per_user_daily BEFORE INSERT ON submissions
FOR EACH ROW
BEGIN
DECLARE cnt INT DEFAULT 0;
SELECT COUNT(*) INTO cnt
FROM submissions
WHERE user_id = NEW.user_id
AND DATE(created_at) = CURDATE();
IF cnt >= 5 THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Daily limit per user exceeded';
END IF;
END$$
DELIMITER ;
- 这里
cnt每次都是针对NEW.user_id实时重算，不依赖上一行结果 - 不能把
SELECT COUNT(*)提到触发器外或用@var缓存，否则第二行起就失效 - 高并发下仍存在竞态（两个会话同时查到 4 条），需搭配计数器表或应用层加锁
真正可控的批量行数限制，不在触发器而在协议和权限层
MySQL 本身没有“单次 INSERT 最大行数”的内置开关，max_allowed_packet 和 bulk_insert_buffer_size 是传输/内存参数，不构成业务逻辑限制。最稳妥的实践是：
- 在连接池或 ORM 层拦截 SQL，正则匹配
INSERT.*VALUES\s*\([^)]+\),\s*\([^)]+\)类模式，提取括号组数 - 给应用账号收回
INSERT权限，只开放特定存储过程调用权限，由过程内部 enforce 批次大小 - 用代理（如 ProxySQL）在 SQL 解析阶段做语法树分析，超限直接拒绝，不进 MySQL 内核
指望触发器精准卡死“单次批量 N 行”，本质是误用了它的设计边界——它擅长行级约束，不负责语句级流量整形。
