应避免在insert触发器中直接用count(*)判断行数超限，因read committed隔离级别下易并发超限；须用tablockx加锁或改用after insert触发器配合rollback与throw抛异常确保一致性。
触发器里用 COUNT(*) 判断行数是否超限，但必须注意事务隔离级别
直接在 INSERT 触发器里查当前表总行数是最直观的做法，但容易出错。比如两个并发插入同时触发，都查到“还没超限”，结果双双写入导致超限。根本原因是默认的 READ COMMITTED 隔离级别下，COUNT(*) 不会阻塞其他插入。
解决办法是显式加锁或改用更严格的隔离逻辑：
- 在触发器内用
SELECT COUNT(*) FROM table_name WITH (TABLOCKX)—— 强制排他表锁，简单粗暴但会严重降低并发写入性能 - 改用
IF (SELECT COUNT(*) FROM table_name) >= @max_rows BEGIN ROLLBACK; THROW 50000, 'Row limit exceeded', 1; END，并确保触发器定义为AFTER INSERT（不能用INSTEAD OF，否则无法依赖实际插入结果） - 避免在触发器里调用函数或视图统计行数，它们可能绕过锁机制，导致判断失效
TRIGGER 中 ROLLBACK 后必须显式 THROW 或 RAISERROR
只写 ROLLBACK 不抛异常，调用方可能收不到错误，误以为插入成功。SQL Server 触发器不会自动传播失败状态。
正确写法示例：
CREATE TRIGGER tr_limit_users ON users
AFTER INSERT
AS
BEGIN
IF (SELECT COUNT(*) FROM users) > 1000
BEGIN
ROLLBACK;
THROW 50000, 'users table row limit (1000) exceeded', 1;
END
END
-
THROW是 SQL Server 2012+ 推荐方式，比RAISERROR更简洁，且能保证错误被客户端捕获 - 错误号必须 ≥ 50000，否则会被视为系统错误，可能触发意外行为
- 不要依赖
@@ERROR判断是否 rollback 成功——它只反映上一条语句，而ROLLBACK自身不改变@@ERROR
用 sys.dm_db_partition_stats 替代 COUNT(*) 可提升性能但不准
对大表来说，全表扫描 COUNT(*) 很慢。有人会用 SELECT rows FROM sys.dm_db_partition_stats WHERE object_id = OBJECT_ID('table_name') AND index_id IN (0,1) 获取近似行数。
但这只是统计信息快照，可能滞后几秒甚至几分钟，尤其在频繁写入场景下：
- 统计信息未及时更新时，
rows值可能远低于真实值，导致“假安全”——实际已超限却没拦截 - 如果表有多个分区，需对所有
index_id IN (0,1)的行求和，漏掉任意一个都会少算 - 仅适用于只读或低频写入表；高一致性要求场景必须坚持用
COUNT(*)+ 锁
触发器限制行数本质是业务规则，应优先考虑应用层或约束设计
靠触发器硬控最大行数，往往暴露了设计问题：比如日志表、临时数据表本该定期归档，而不是卡死插入。
真正健壮的做法是：
- 用
DELETE TOP (N) ... ORDER BY timestamp DESC配合作业定时清理，比拦插入更可控 - 对必须限制的配置表，改用唯一约束 + 计数器表（如单独一张
table_row_counts），由应用维护，避免触发器开销 - SQL Server 本身不提供原生行数限制语法，任何触发器方案都是折衷——它增加了写入延迟、死锁风险，且无法防止
BULK INSERT绕过（除非禁用TABLOCK）
触发器里的行数检查，最容易被忽略的是并发窗口期和统计延迟，不是写完就万事大吉。
