健全性检查
发布: (2026年1月5日 GMT+8 22:57)
3 min read
原文: Dev.to
Source: Dev.to
为什么要进行完整性检查
生产环境中会出现各种奇怪的情况。再多的测试覆盖率、数据库事务或多年经验,都无法保证不会出现意外问题。
对数据库运行完整性检查脚本可以在这些异常演变成重大问题之前将其捕获。根据我的经验,这种做法在过去二十年里一直很可靠。
何时添加完整性检查
每当你引入无法(或不易)直接由数据库强制执行的业务规则时,添加一个基本检查,扫描违反这些规则的记录。
示例规则
规则: 当 state = 'paid' 时,paid_at 不应为 NULL。
-- Find records where the rule is violated
SELECT *
FROM payments
WHERE state = 'paid' AND paid_at IS NULL;
将结果发送到你的告警系统(例如 PagerDuty、Slack、邮件)。
常见完整性检查模式
-
超出外键的参照完整性
对象 X 属于对象 Y,且两者应拥有相同的所有者 Z。 -
最小关系要求
- 所有用户必须至少属于一个组织。
- 所有组织必须至少拥有一个用户。
-
特殊情况约束
- 标记为超级管理员的用户只能属于组织
Foo。
- 标记为超级管理员的用户只能属于组织
运维建议
- 频率 – 对关键约束每隔几分钟运行一次检查(例如每 5 分钟),对不太紧急的约束可安排为每日批处理。
- 范围 – 将检查限制在过去 48 小时内创建或更新的记录,以减少噪音。
- 排除项 – 对已归档的记录忽略检查,如果它们与当前业务无关。
- 部署前运行 – 在部署新代码前手动执行检查,避免因不完整或有缺陷的完整性检查逻辑导致大量误报淹没告警系统。
通过将这些简单查询纳入监控流水线,你可以及早捕获数据异常,保持生产系统的健康。