SQL数据校验需分层实践，数据库层用NOT NULL、UNIQUE、CHECK约束和触发器守住写入底线，辅以校验视图与物化表暴露问题，但需协同应用层等其他层级。
SQL数据校验不是“加个CHECK约束就完事”，而是一套分层、可落地、兼顾性能与准确性的实践组合。数据库层校验是其中最刚性、最不可绕过的一环，它直接守住数据写入的底线。
用约束守住数据合法性底线
NOT NULL、UNIQUE、PRIMARY KEY 是基础但常被忽视的校验手段。它们在INSERT/UPDATE时由数据库引擎自动执行，零额外开销，且对应用透明。
- 字符串字段若业务上不允许空值，优先用 NOT NULL，而非让应用层判断空字符串或NULL再报错
- 手机号、身份证号等唯一性标识，除业务逻辑去重外，必须加 UNIQUE 约束，防止并发插入导致脏数据
- CHECK约束适合轻量级逻辑校验：如年龄字段 age INT CHECK (age BETWEEN 0 AND 150)，订单状态字段 status VARCHAR(20) CHECK (status IN ('draft', 'paid', 'shipped', 'cancelled'))
注意：MySQL 8.0.16+ 才完整支持 CHECK；旧版本可用触发器模拟，但会增加维护成本和性能损耗。
用触发器处理跨字段/跨表复杂规则
当校验逻辑涉及多列计算、关联表查询或需调用函数时（如“订单总金额 = 各明细行金额之和”），触发器是数据库层最可控的选择。
- 推荐使用 BEFORE INSERT / BEFORE UPDATE 触发器，在数据落盘前拦截非法变更
- 避免在触发器中做远程调用、大表扫描或事务内更新其他业务表，否则易引发死锁或性能抖动
- 错误提示应明确：用 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '订单明细金额不匹配'，便于应用层识别并反馈用户
用只读视图+物化校验表暴露数据质量问题
不是所有问题都适合“堵”，有些更适合“疏”。对历史数据、ETL结果或报表口径一致性，可建校验视图或定时刷新的校验表。
- 例如建视图 v_order_consistency：JOIN 订单主表与明细表，筛选 sum(detail.amount) ≠ order.total 的异常记录
- 配合监控任务定期查该视图，发现即告警，不阻断业务流，但确保问题可追溯
- 对高频校验场景，可用定时任务将结果写入 data_quality_log 表，保留时间窗口内的校验快照
规避常见陷阱：约束≠万能，校验需协同
数据库层校验强大，但有明确边界：
- 无法替代应用层的业务规则（如“用户A不能给自己转账”需结合上下文权限判断）
- NULL值语义模糊：CHECK(age > 18) 对NULL不生效，需显式写成 age IS NOT NULL AND age > 18
- 字符集与排序规则影响校验：WHERE name = '张三' 在 utf8mb4_0900_as_cs 下区分大小写和重音，测试环境必须与生产一致
- 批量导入（LOAD DATA、INSERT ... SELECT）可能绕过部分触发器或约束，需单独验证脚本逻辑
真正的数据质量，靠的是应用层校验、数据库层约束、中间件拦截、离线稽核四层联动。数据库层是最后一道闸门，也是最不该失守的一道。
