SIGNAL 是 MySQL 5.5+ 在 BEFORE INSERT 触发器中唯一可靠的中断方式；低版本无法可靠阻断，且 SELECT COUNT(*) 会引发死锁、MVCC 快照偏差或报错，加锁、ROLLBACK、函数封装等均不可行。
MySQL 5.5+ 可以用 SIGNAL 在 BEFORE INSERT 触发器中干净中断插入，这是唯一推荐的“硬限制”做法；低于 5.5 的版本无法可靠阻断，别硬套。
为什么不能在触发器里直接写 SELECT COUNT(*) FROM my_table
InnoDB 引擎下，BEFORE INSERT 触发器中执行该查询会尝试对当前表加一致性读锁，而插入事务本身已持有行级锁，极易触发死锁或报错：Can't update table 'my_table' in stored function/trigger。即使侥幸不报错，也可能因 MVCC 快照看到“不含当前待插入行”的旧计数，导致实际超限仍放行。
- MySQL 5.7+ 默认事务隔离级别为
REPEATABLE READ，更强化了该问题 - 用
SELECT COUNT(*) INTO @cnt FROM my_table也不解决根本冲突，只是把错误延迟到运行时 - 别信“加
LOCK IN SHARE MODE就能查”的说法——触发器里禁止显式加锁操作
SIGNAL 是唯一可靠的中断方式（MySQL 5.5+）
它不依赖数据变更、不触发额外锁、不修改任何表，纯粹抛出 SQLSTATE 错误让客户端感知失败。必须配合 DELIMITER 和明确的 SQLSTATE 使用。
-
SIGNAL SQLSTATE '45000'是通用未定义错误码，安全可用 - 必须写在
IF判断块内，且条件要基于真实行数（哪怕慢） - 示例：限制
logs表最多 10000 行
DELIMITER $$
CREATE TRIGGER limit_logs_before_insert
BEFORE INSERT ON logs
FOR EACH ROW
BEGIN
DECLARE row_count INT DEFAULT 0;
SELECT COUNT(*) INTO row_count FROM logs;
IF row_count >= 10000 THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'logs table reached max capacity (10000)';
END IF;
END$$
DELIMITER ;
注意：row_count 查询仍会全表扫描，大表慎用；生产环境若频繁插入，应评估是否真需硬限制，还是改用分区 + 定时归档。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
常见错误写法及后果
这些看似“能跑通”的写法，实际埋雷：
- 用
CALL some_procedure()模拟报错：函数内部无法SIGNAL，调用后继续执行插入，等于没限制 - 写
INSERT INTO error_log VALUES (...)再ROLLBACK：触发器里不允许ROLLBACK，报错且事务状态不可控 - 删最老行再放行（如
DELETE ... ORDER BY created_at ASC LIMIT 1）：MySQL 禁止在BEFORE INSERT中修改本表，直接报错 - 把
COUNT(*)封装进存储函数再调用：函数执行上下文独立，返回值常为 0 或报错，不可信
真正难的不是写触发器语法，而是接受一个事实：每次插入都扫一遍表来计数，在高并发或大数据量下本身就是反模式。硬限制只适合小表、低频写入、强语义场景（如配置开关表、单例元数据表）。其他情况，请优先考虑应用层拦截或定时清理机制。
