MySQL 5.5+ 才能用 SIGNAL 在 BEFORE INSERT 中可靠中断插入；低于该版本无法实现硬限制，且触发器内禁止修改当前表、显式加锁或执行 DELETE，COUNT(*) 判断仅作阈值检查，SIGNAL 是唯一干净中断方式。
MySQL 5.5+ 才能用 SIGNAL 在 BEFORE INSERT 中可靠中断插入；低于这个版本，任何“硬限制”方案都会出问题，别硬上。
为什么不能在触发器里直接 SELECT COUNT(*) 然后 DELETE
常见错误是写成“查总数 → 超限就删最老一行”。这在 MySQL 触发器里根本跑不通：
-
DELETE FROM logs ORDER BY created_at LIMIT 1会报错Can't update table 'logs' in stored function/trigger—— MySQL 明确禁止在触发器中修改当前表 -
SELECT COUNT(*) INTO @cnt FROM logs看似可行，但实际会因 MVCC 快照偏差漏判：事务开始时的快照不含本次待插入行，导致计数偏小，超限仍放行 - 加
LOCK IN SHARE MODE或显式SELECT ... FOR UPDATE也不行——触发器内禁止显式加锁，会直接报错 - 哪怕用临时表绕开、或调用存储过程，最终执行删操作时仍要避开本表，逻辑复杂且无法保证原子性
SIGNAL SQLSTATE '45000' 是唯一推荐的硬限制方式
它不读表、不删行、不加锁，纯粹抛异常让客户端感知失败，干净且可控：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须写在
BEFORE INSERT触发器里，且放在IF判断块内 -
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'table reached max capacity (10000)'是安全通用写法，'45000'表示未定义的用户异常 - 需配合
DELIMITER $$避免分号提前结束语句 - 查询行数仍需
SELECT COUNT(*) INTO row_count FROM logs，但只用于判断，不用于修改
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 ;
大表慎用，生产环境优先考虑替代方案
每次插入都全表扫描 COUNT(*)，对百万级表就是性能黑洞：
- 即使加了索引，
COUNT(*)仍需遍历聚簇索引或二级索引叶子节点，无法跳过扫描 - 高并发插入下，COUNT 结果可能瞬间过期（刚查完就有人插入），但至少不会超限——这是
SIGNAL方案的底线保障 - 真正生产环境几乎不用纯触发器控行数：分区表 + 定时归档（如按月分区、自动
DROP PARTITION）更稳 - 若业务允许“近似上限”，可用独立计数器表（
t1_count）配合AFTER INSERT/AFTER DELETE触发器维护，避免每次 COUNT 扫描主表
硬限制的本质不是“技术能不能做”，而是“值不值得为精确性牺牲写入性能和可维护性”。SIGNAL 是唯一干净的中断手段，但它的代价是每次插入都多一次全表 COUNT —— 这个开销，得你自己掂量。
