SQL Server 用 IF+THROW/RAISERROR、MySQL 用 SIGNAL、PostgreSQL 用 RAISE EXCEPTION 实现入库前校验，核心是“该不该存”，须置于 INSERT 前、配合事务与异常处理确保数据一致性。
SQL Server 里用 IF + RAISERROR 做入库前校验最直接
存储过程中做数据校验，核心不是“能不能存”，而是“该不该存”。SQL Server 没有像触发器那样自动拦截的机制，得靠显式判断 + 主动报错来中断执行。用 IF 检查条件，不满足就调 RAISERROR（或 THROW），SQL Server 会立刻终止后续语句——这是最可控、最易调试的方式。
常见错误现象：INSERT 语句照常执行，但校验逻辑被写在 INSERT 后面，结果数据已入库才报错；或者只用 PRINT 提示，根本拦不住写入。
- 校验逻辑必须放在
INSERT/UPDATE之前 - 优先用
THROW 50000, '校验失败', 1（SQL Server 2012+），比RAISERROR更简洁且能中止批处理 - 避免在循环体里反复校验单行数据，应先用
SELECT COUNT(*)或EXISTS做集合级判断，再统一处理
MySQL 存储过程里没有 THROW，得靠 SIGNAL 主动中断
MySQL 5.5+ 支持 SIGNAL，它是唯一能真正终止当前存储过程执行并返回错误码的语句。用 SELECT 'error' 或 LEAVE 跳出标签都不够——前者不报错，后者可能让上层应用误以为成功。
使用场景：比如插入订单前检查用户余额是否足够，不能只查完就插，必须确保检查通过后才走下一步。
-
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '余额不足';是标准写法，45000表示通用未定义异常 - 别把校验逻辑塞进
INSERT …… SELECT的子查询里，MySQL 不允许子查询中调SIGNAL - 如果过程里有事务，
SIGNAL不会自动回滚，得配合DECLARE EXIT HANDLER FOR SQLEXCEPTION显式ROLLBACK
PostgreSQL 用 RAISE EXCEPTION 配合 EXCEPTION 块更灵活
PostgreSQL 的存储过程（函数）默认是原子性的，但校验失败时若只靠 RAISE NOTICE，数据照样入库。必须用 RAISE EXCEPTION 触发异常，并用 BEGIN …… EXCEPTION 块包裹关键逻辑，才能精准控制回滚边界。
参数差异：RAISE EXCEPTION '%', v_msg 中的 % 是占位符，支持多个参数拼接，比硬拼字符串安全。
- 不要把整个
INSERT写在无异常捕获的顶层，否则校验失败后无法保证一致性 - 如果校验依赖其他表数据，注意
READ COMMITTED隔离级别下可能被并发修改，必要时加SELECT …… FOR UPDATE -
RAISE EXCEPTION会自带错误码（如P0001），应用层可据此区分业务异常和系统异常
跨数据库校验逻辑容易踩的坑：NULL、空字符串、时区、精度
规则看似简单，一到具体字段就翻车。比如校验“手机号不能为空”，在 PostgreSQL 里 '' 和 NULL 是两回事；SQL Server 默认把空字符串当 NULL 处理（取决于 ANSI_NULLS 设置）；MySQL 则严格区分。
性能影响：在 WHERE 条件里写 LEN(@phone) != 11（SQL Server）或 CHAR_LENGTH(phone) 11（MySQL）会阻止索引使用，应提前用变量存长度再判断。
- 统一用
IS NULL或COALESCE(col, '') =''显式处理空值，别依赖数据库默认行为 - 日期类校验（如“不得晚于当前时间”）务必用
GETDATE()/NOW()/CURRENT_TIMESTAMP，别传字符串进来再转 - 金额类字段校验精度，避免用
FLOAT做等值判断，改用ABS(a - b)
复杂点在于，同一套校验逻辑移植到不同数据库时，连“非空”的定义都可能不一致。别指望一次写完到处跑，得按目标库特性重写判断分支。
