MySQL和PostgreSQL的BEFORE INSERT触发器中不可直接用COUNT(*)查当前表，易致死锁或报错；应改用变量暂存、应用层计数或独立计数表，MySQL 5.5+可用SIGNAL中断插入。
触发器里不能直接用 COUNT(*) 查询当前表
MySQL 和 PostgreSQL 的 BEFORE INSERT 触发器中，如果在触发器体里写 SELECT COUNT(*) FROM my_table，会报错或死锁——因为正在插入的行还没提交，而查询又试图加读锁或快照锁，尤其在 InnoDB 下容易触发 “Can't update table ‘my_table’ in stored function/trigger” 类错误。
实操建议：
- 改用
SELECT COUNT(*) INTO @cnt FROM my_table在支持变量赋值的引擎（如 MySQL）中暂存结果，但必须确保触发器是DEFINER权限且不涉及事务冲突 - 更稳妥的做法：把计数逻辑移到应用层，或用带版本号/时间戳的轻量级计数表（如
table_row_count）单独维护，避免每次插入都扫全表 - PostgreSQL 用户注意：
BEFORE触发器中禁止执行任何修改数据的语句（包括SELECT ... FOR UPDATE），所以连“先查再锁”的路也走不通
MySQL 中用 SIGNAL 主动中断插入
MySQL 5.5+ 支持 SIGNAL 抛出自定义 SQLSTATE 错误，这是阻断插入最干净的方式。别用 INSERT INTO ... SELECT 或 UPDATE 模拟失败——既不可靠，又可能留下脏数据。
实操示例（限制 users 表最多 1000 行）：
DELIMITER $$
CREATE TRIGGER limit_users_before_insert
BEFORE INSERT ON users
FOR EACH ROW
BEGIN
DECLARE row_count INT DEFAULT 0;
SELECT COUNT(*) INTO row_count FROM users;
IF row_count >= 1000 THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'users table is full';
END IF;
END$$
DELIMITER ;
注意点：
-
SIGNAL只在 MySQL 5.5+ 有效；MariaDB 也支持，但旧版需确认是否启用sql_mode中的STRICT_TRANS_TABLES - 触发器中
COUNT(*)虽然慢，但在小表（ - 不要在触发器里调用存储函数封装
COUNT——函数内无法捕获触发器上下文，容易返回 0 或报错
PostgreSQL 怎么绕过“不能查本表”的限制
PostgreSQL 的 BEFORE INSERT 触发器函数里执行 SELECT COUNT(*) FROM my_table 不报错，但会看到“未提交前的快照”，也就是不包含当前正插入的那行——导致实际超限时仍能插进第 N+1 行。
正确做法是用 pg_class 查统计信息（近似但够用），或用事务级计数器：
- 查
pg_class：用SELECT reltuples::BIGINT FROM pg_class WHERE relname = 'my_table'，返回的是 ANALYZE 后估算值，误差可能达 10%~20%，适合对精确性要求不高的场景 - 用序列 + 计数表：建一张
my_table_counter存当前行数，触发器里先SELECT FOR UPDATE读、再判断、再UPDATE，全程加行锁保证一致性 - 别在触发器里写
PERFORM pg_sleep(0.001)试图“等一等”——没用，快照已固定
真正影响性能的是“每次插入都 COUNT”
无论用哪种数据库，只要触发器里每插一行就扫一次全表，当表增长到几万行后，INSERT 延迟会从毫秒级跳到百毫秒级，QPS 断崖下跌。
必须权衡的点：
- 硬限制最大行数本身就很罕见，多数需求其实是“滚动保留最近 N 条”，这时该用分区表 + 定时清理，而不是靠触发器卡住写入
- 如果真要精确控制，优先在应用层做
INSERT前SELECT COUNT(*)+ 业务逻辑判断，把失败反馈给用户，比数据库报错更友好 - 哪怕用了计数表，也要注意：高并发下多个插入同时读到相同计数值，然后一起通过校验再一起更新，可能突破上限——得靠
SELECT ... FOR UPDATE或原子自增操作兜底
触发器不是万能的计数开关，它只是最后那道门；门框钉多牢，取决于你愿不愿意在门外先修好路。
