MySQL触发器无法可靠实现硬性行数限制：BEFORE INSERT中COUNT(*)因快照隔离导致并发超限，AFTER INSERT无法回滚；唯一约束、独立计数器表或应用层分布式锁才是可行方案。
MySQL 触发器无法可靠实现“硬性限制表最大行数”——因为 AFTER INSERT 触发器无法回滚已发生的插入，而 BEFORE INSERT 中查 COUNT(*) 在高并发下会失效。
为什么 BEFORE INSERT + COUNT(*) 不安全
这是最常被尝试的方案，但实际线上几乎必然出错：
-
COUNT(*)在BEFORE INSERT里读的是“当前快照”，不包含本事务刚插入但未提交的其他行（即使同一事务中多条INSERT，COUNT(*)也看不到前面几条） - 两个并发事务同时查到行数为 99，都允许插入第 100 行，结果变成 101 行
- 加
SELECT ... FOR UPDATE能缓解但代价极高：所有插入都会串行化，吞吐暴跌，还可能死锁
真正可行的替代方案：用唯一约束模拟计数器
核心思路是把“行数上限”转为“主键/唯一键范围控制”，绕过并发读写竞争：
- 给目标表加一个自增
id（或新增seq列），设为PRIMARY KEY - 在应用层或存储过程里控制插入前检查：
SELECT MAX(seq) FROM table_name，再判断是否< 100 - 更稳妥的做法：建一张独立的计数器表
table_limit_counter，仅含一列current_count INT，每次插入前用UPDATE table_limit_counter SET current_count = current_count + 1 WHERE current_count < 100—— 这条语句自带原子性，影响行为 0 或 1，可直接判断是否成功
如果坚持用触发器，只能做软提示而非拦截
触发器能做的极限是记录超限行为，不能阻止插入成功：
DELIMITER $$
CREATE TRIGGER check_row_limit BEFORE INSERT ON your_table
FOR EACH ROW
BEGIN
DECLARE row_count INT DEFAULT 0;
SELECT COUNT(*) INTO row_count FROM your_table;
IF row_count >= 100 THEN
INSERT INTO audit_log (msg) VALUES (CONCAT('Insert rejected: table reached limit at ', NOW()));
END IF;
END$$
DELIMITER ;
注意：INSERT INTO audit_log 成功不代表原插入被取消——your_table 该插还是插了。MySQL 不允许在 BEFORE 触发器里抛出用户错误中断执行（5.7+ 可用 SIGNAL SQLSTATE '45000'，但兼容性和事务行为不稳定，不建议依赖）。
真要强一致性限行，别碰触发器；要么用应用层加分布式锁（如 Redis），要么改用带事务级序列支持的数据库（如 PostgreSQL 的 SEQUENCE 配合 BEFORE INSERT 检查）。MySQL 的触发器在这里就是个温柔的陷阱。
