优先写在 SQL 里。数据库层校验能早暴露问题、避免脏数据入库，且批量校验更高效；但复杂业务规则应放应用层，SQL 适合 CHECK 约束、格式、范围、外键等校验，需注意性能、兼容性与可维护性。
校验逻辑该写在 SQL 还是应用层？
优先写在 SQL 里。数据库层校验能早暴露问题、避免脏数据入库，且对批量校验（比如每日跑一次全量数据比对）更高效。但要注意：复杂业务规则（如“用户等级变更需同步更新积分有效期”）不适合塞进 SQL，容易变成难以维护的嵌套 CASE WHEN 或临时表链。
- 适合 SQL 校验的场景：
CHECK约束、NOT NULL、字段格式（用REGEXP_LIKE或LIKE）、数值范围（WHERE amount ）、外键缺失（LEFT JOIN ... WHERE ref_id IS NULL） - SQL 校验的代价：全表扫描可能锁表或拖慢查询；某些函数（如
REGEXP_LIKE）在 MySQL 8.0 前不支持，PostgreSQL 需开启pg_trgm - 别把校验逻辑硬编码进报表 SQL —— 把规则抽成视图或 CTE，例如建一个
v_data_quality_rules视图存各字段预期值域，再JOIN校验
如何让校验结果可读又可追踪？
直接 SELECT * FROM t WHERE status NOT IN ('active', 'inactive') 只告诉你“有异常”，但不知道哪条记录、哪个时间点、谁触发的。必须带上下文。
- 每条校验结果至少包含四列：
check_name（如'order_amount_negative'）、table_name、record_id（主键或业务唯一键）、check_time（用NOW()或调度时间戳） - 用
UNION ALL合并多条校验，避免多个独立查询难聚合 —— 但注意各子查询列名和类型要严格一致，否则 PostgreSQL 会报错，MySQL 可能静默转类型 - 示例片段：
SELECT 'null_phone' AS check_name, 'users' AS table_name, id AS record_id, NOW() AS check_time FROM users WHERE phone IS NULL OR TRIM(phone) = ''
怎么避免校验报表越跑越慢？
校验逻辑随业务增长不断叠加，全表扫一遍可能从 2 秒涨到 15 分钟。关键不是加索引，而是控制校验粒度。
手绘涂鸦教育信息图表矢量素材
下载
手绘涂鸦教育信息图表矢量素材适用于企业报告、项目管理工具、效率提升研讨会、时间线图表、商务演示文稿、数据分析报告、教育和培训材料、时间管理软件界面、会议和研讨会宣传材料、年度业绩回顾、员工绩效评估、市场研究和分析报告以及任何需要展示时间管理和统计数据的商务场合。设计的AI格式素材。
- 区分「强校验」和「弱校验」：强校验（如主键重复、金额为负）走实时触发器或事务内检查；报表只跑弱校验（如“近 7 天订单中，95% 的收货地址应含省名”），且加
WHERE create_time >= CURRENT_DATE - INTERVAL '7 days' - 对大表，用采样校验代替全量：PostgreSQL 可用
TABLESAMPLE SYSTEM (1)，MySQL 8.0+ 支持SELECT ... FROM t TABLESAMPLE (1) - 禁止在
WHERE中对字段做函数操作（如WHERE UPPER(email) = 'A@B.COM'），会导致索引失效 —— 应该在校验前统一清洗，或建函数索引
校验失败后怎么通知和修复？
报表跑出 127 条异常，没人看等于没校验。得把结果导出成结构化数据，而不是截图发钉钉。
- 输出格式优先选 CSV 或 JSON：CSV 方便 Excel 打开排查，JSON 适合程序解析（比如自动创建 Jira issue）；避免 HTML 表格，解析成本高且易被邮件客户端过滤
- 在 SQL 中用
STRING_AGG拼接问题详情（如STRING_AGG(DISTINCT CONCAT('id=', id, ', phone=', phone), '; ')），避免一行一记录导致结果集过大 - 最常被忽略的一点：校验 SQL 必须带
timeout控制（如 PostgreSQL 的statement_timeout = '30s'），否则某条慢校验卡住整个调度任务，后续日报全断
