SQL Server用RAISERROR、PostgreSQL用RAISE EXCEPTION、MySQL用SIGNAL+DECLARE HANDLER实现业务约束校验，三者语法语义事务行为均不同，无法跨库兼容，需依数据库特性选择并配合事务隔离级别。
SQL Server 存储过程中用 RAISERROR 检查业务约束
存储过程里不能靠外键或 CHECK 约束覆盖所有业务规则，比如“同一用户当天最多下单 3 次”这种逻辑，得手动写断言。最直接的方式是查表、判断条件，不满足就中断执行并报错——RAISERROR 是 SQL Server 里最可控的选择，比 THROW 兼容性更好（支持 2005+），也比直接让语句失败更清晰。
常见错误现象：Msg 50000, Level 16, State 1 这类自定义错误没被上层捕获，导致应用端只看到“执行失败”，不知道具体哪条业务规则被违反；或者用了 PRINT，结果只是输出日志，事务照常提交。
- 必须配合
IF NOT EXISTS (SELECT ...)或IF @count > 3这类显式判断，不能只依赖查询返回空集就默认通过 - 错误级别建议用
16（用户可修复错误），避免用20+导致连接中断 - 加
WITH LOG仅在调试期需要，生产环境会拖慢性能且填满 errorlog - 示例：检查用户当日订单数
IF (SELECT COUNT(*) FROM Orders WHERE UserId = @UserId AND CAST(OrderTime AS DATE) = CAST(GETDATE() AS DATE)) >= 3
RAISERROR('用户 %d 当日订单已达上限', 16, 1, @UserId)
PostgreSQL 中用 RAISE EXCEPTION 做断言校验
PostgreSQL 没有 RAISERROR，对应的是 RAISE EXCEPTION，它天然属于事务控制流的一部分：一旦触发，当前事务块立即退出，无需额外 ROLLBACK。但要注意，它只在 PL/pgSQL 函数/过程里生效，普通 SQL 脚本中无效。
容易踩的坑：RAISE NOTICE 看起来像断言，其实只是日志，事务继续；还有人误用 ASSERT，但它只在 plpgsql_check 扩展启用时才起作用，不是内建行为。
-
RAISE EXCEPTION的消息模板支持%L（带引号字符串）、%I（标识符）等占位符，防止 SQL 注入 - 错误码建议用自定义前缀，如
RAISE EXCEPTION 'BUSINESS_RULE_VIOLATED' USING ERRCODE = 'P0001'，方便应用层区分 - 在
BEFORE INSERT OR UPDATE触发器里做校验更早，但存储过程里做更适合跨多表、含计算逻辑的断言
MySQL 存储过程中 SIGNAL 不等于断言，得配 DECLARE HANDLER
MySQL 5.5+ 的 SIGNAL 本身只是抛出错误，不会自动终止后续语句——这点和 SQL Server / PostgreSQL 完全不同。如果没配 DECLARE HANDLER，存储过程会继续跑完，可能造成数据不一致。
典型翻车现场：写了 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '库存不足'，但没加 DECLARE EXIT HANDLER FOR SQLEXCEPTION，结果扣减库存的 UPDATE 还是执行了。
- 必须声明
EXIT HANDLER，且类型要匹配，FOR SQLEXCEPTION比FOR SQLWARNING更稳妥 -
SIGNAL的SQLSTATE推荐用'45000'（通用未定义异常），避免和系统状态码冲突 - 不要在循环里频繁
SIGNAL，MySQL 对异常处理开销敏感，批量校验建议先聚合结果再统一报错
跨数据库兼容的断言写法几乎不存在，别硬套
想写一个“到处都能跑”的断言逻辑？现实是：SQL Server 用 RAISERROR，PostgreSQL 用 RAISE EXCEPTION，MySQL 用 SIGNAL + HANDLER，Oracle 用 RAISE_APPLICATION_ERROR。语法、语义、事务行为全都不一样。
真正该关注的不是“怎么统一”，而是“在哪一层校验更合理”。比如金额精度校验放应用层比放存储过程里更容易测试和复用；而涉及多行锁、强一致性要求的（如“账户余额不能为负”），就必须在数据库层用原生机制拦截。
最容易被忽略的一点：所有这些断言都依赖正确的事务隔离级别。比如在 READ COMMITTED 下检查库存，可能刚查完就被别人扣掉，得配合 SELECT ... FOR UPDATE 或应用乐观锁。否则断言只是纸面正确。
