触发器中禁止直接SELECT COUNT(*)查当前表，否则引发mutating table错误（Oracle）或死锁（MySQL/PG）；应改用计数器表、自治事务（Oracle）、pg_class.reltuples（PG）或应用层控制。
触发器里怎么判断当前表已有多少行
直接查 COUNT(*) 是最直观的想法，但要注意：在 BEFORE INSERT 触发器中执行 SELECT COUNT(*) FROM 表名 会引发“变异表（mutating table）”错误（Oracle）或锁等待/死锁风险（MySQL / PostgreSQL）。这不是语法错，而是数据库为保证一致性禁止在触发器里读写正在被修改的同一张表。
更稳妥的做法是用一个独立计数器表（比如 table_row_count），由触发器维护它；或者改用应用层控制——但如果你必须用触发器，就得绕开直接查原表：
- MySQL 可在
BEFORE INSERT中用(SELECT COUNT(*) FROM 表名)（支持，但会加共享锁，高并发下可能卡住） - PostgreSQL 推荐用
pg_class.reltuples近似值（不精确，但快且无锁），例如：(SELECT reltuples::BIGINT FROM pg_class WHERE relname = 'your_table') - Oracle 必须用自治事务（
AUTONOMOUS_TRANSACTION）封装查询，否则报 ORA-04091
INSERT 被拒绝时该用什么方式中断
不能靠 RETURN 或 EXIT——那只是退出触发器逻辑，插入仍会发生。必须显式抛出异常让整个语句失败：
- MySQL：用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Row limit exceeded' - PostgreSQL：用
RAISE EXCEPTION 'Row limit exceeded' - SQL Server：用
THROW 50000, 'Row limit exceeded', 1 - Oracle：用
RAISE_APPLICATION_ERROR(-20001, 'Row limit exceeded')
注意：MySQL 5.5+ 才支持 SIGNAL；老版本只能靠制造一个必然失败的操作（比如向不存在的表插入）来间接中断，极不推荐。
最大行数限制是硬编码还是可配置
硬编码（比如写死 IF (count >= 1000) THEN ...）会让维护变困难。建议把上限存在单独配置表里：
CREATE TABLE table_limits (
table_name VARCHAR(64) PRIMARY KEY,
max_rows INT NOT NULL
);
INSERT INTO table_limits VALUES ('orders', 5000);
触发器中动态查这张表，就能统一管理多张表的限额。但要小心：每次 INSERT 都查一次配置表，会增加 I/O 和锁竞争。如果上限极少变动，可以考虑用数据库变量（MySQL @max_orders）或应用启动时加载到内存缓存。
为什么不用 CHECK 约束或唯一索引替代
CHECK 约束只能校验单行数据，无法统计全表行数；唯一索引也解决不了数量限制问题。有人试图用「自增 ID > N 就拒绝」，但这在有 DELETE、REPLACE 或手动指定 ID 的场景下完全失效。触发器是目前唯一能在 DML 层面做全局行数拦截的通用机制——但它代价高、难调试、跨数据库不兼容，真正上线前务必压测并发插入场景。
实际项目中，更常见的做法是：在应用层做「先查再插」+ 分布式锁兜底，把压力从数据库移到服务端；触发器只作为最后一道防御，且上限值必须留出缓冲余量，避免因统计延迟导致误拒。
