SQL 判断一组检查全部通过，为什么只看 MIN 或 BOOL_AND 不够？
本文目录
面试怎么回答
我会先建立应执行检查项的清单，再匹配实际结果。MIN和BOOL_AND可能忽略空值，更不能发现根本不存在的检查行，因此要分别统计应有、通过、失败和未知数量。只有覆盖完整且全部合格才按规则放行；没有应执行项的空集合单独定义，不能靠COALESCE为true默认通过。重复重试结果还要先选可信版本。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
十项质量检查只返回了九项，其中九项全部成功。此时MIN结果等于1，BOOL_AND也可能得到true，但这批数据真的通过了十项检查吗？没有失败证据，不等于成功证据齐全。
全部通过既要求已执行结果合格，也要求应执行项完整；空值、缺失行和空集合必须先定义，不能被聚合静默忽略。
聚合看得到输入行，看不到应该存在的行
假设状态用一表示通过、零表示失败，MIN只能总结送进来的值。如果缺失的检查项没有对应记录，函数根本不知道还欠一项。
以 PostgreSQL 17 为例，MIN和BOOL_AND会忽略空输入值。九个true加一个NULL，布尔聚合可能仍是true；全空或完全没有输入时，又涉及返回NULL的规则。
这些都是函数语义，不是质量平台的完整放行逻辑。把函数返回值直接当成“全部通过”，等于把数据覆盖假设藏在SQL之外。
应有清单必须独立于实际结果
先确定某批次按哪个规则版本应执行哪些检查项，再从这个全集关联实际运行结果。只有这样，LEFT JOIN后缺失的那一侧才能成为可识别的未完成状态。
若反过来从结果表出发GROUP BY，只会出现已经返回结果的检查。整批一条结果都没有时，连批次本身都可能不在报表里。
清单也需要版本：规则今天新增，不意味着昨天必须执行同一套检查。把当前规则全集直接套到所有历史批次，会制造另一种假缺失。
先把重复执行压成可信结果，再统计
同一个检查可能失败后重试，也可能产生重复回调。匹配前应按批次与检查项保留明确认可的运行版本，不要让一项检查通过两次就填补另一项缺失。
下面是 PostgreSQL 17 风格示例。假设expected_checks中本批次每项唯一，check_result_latest已按明确规则选出每项可信结果，passed为布尔值：
SELECT e.batch_id,
COUNT(*) AS expected_count,
COUNT(*) FILTER (WHERE r.passed IS TRUE) AS passed_count,
COUNT(*) FILTER (WHERE r.passed IS FALSE) AS failed_count,
COUNT(*) FILTER (WHERE r.passed IS NULL) AS unknown_count
FROM expected_checks e
LEFT JOIN check_result_latest r
ON r.batch_id = e.batch_id
AND r.check_id = e.check_id
GROUP BY e.batch_id;这里将没有返回结果和结果为NULL都归入未知。若运行系统能区分未开始、执行中、技术失败和业务不合格，应进一步细分，而不是把它们全部改成检查不通过。
放行条件必须对应业务风险
对必须全部完成的检查，可以要求应有项数大于零、通过项数等于应有项数。若有可豁免项，豁免必须有明确版本、原因和批准记录，不能靠漏掉这项实现。
批次没有任何应执行项时，上面的查询不会自动产出一行。需要从批次清单再做关联，并按规则处理“未配置检查”，而不是用缺少告警代表成功。
有些流程允许非关键检查异步完成，也应给出“关键检查通过、非关键待完成”的独立状态。聚合结果可以服务这种分级，但不能替代分级定义。
一个典型场景：检测服务故障反而让数据放行
假设一个检查服务异常，没有写入结果，发布流程却显示所有检查通过。开始认为服务已经恢复，只是日志延迟。
排查后发现SQL只统计已返回的成功记录，未执行项没有入表。旧验收使用的样本都是完整检查集，完全没有模拟服务不返回结果的情况。
修正引入版本化应有清单，把实际结果LEFT JOIN回来，并将缺失项列为待处理。验收增加零返回、部分返回、重复回调、失败后重试及规则临时调整等场景。
告警和验收应展示缺了哪一项
仅显示总分或一个绿灯，排查仍需要翻多处日志。可以直接给出缺失检查ID、最近运行状态、所属批次和规则版本，让负责人知道应该补跑还是调查源数据。
这道题并不是说MIN或BOOL_AND不好用，而是提醒我们：聚合函数只总结观察到的事实，完整性必须由另一份应有事实来证明。