bool_and跳过null值，仅对非null值执行逻辑与运算：全为true则返回true，存在false则返回false，全为null则返回null。
因为BOOL_AND直接对布尔值做短路式归约，不依赖类型转换、不扫描NULL、语义清晰且索引友好。
BOOL_AND如何处理NULL值？
它跳过NULL，只基于非NULL值计算结果：只要组内所有非NULL值为true，结果就是true；只要有一个false，结果就是false；如果全为NULL，则返回null（不是false）。
常见错误现象：
- 误以为
BOOL_AND(flag)返回false就代表“存在false”，其实也可能是“全NULL” - 在WHERE中直接写
BOOL_AND(flag) = true却忽略NULL导致漏数据
正确做法是显式排除NULL干扰：
SELECT dept, BOOL_AND(active IS TRUE) AS all_active FROM users GROUP BY dept;
这里用active IS TRUE把NULL转为false，确保逻辑可预测。
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
和BIT_AND(status)比，为什么BOOL_AND更安全？
BIT_AND在PostgreSQL里根本不存在——它会直接报错function bit_and(integer) does not exist。而BOOL_AND是标准SQL聚合函数，原生支持、语义明确。
使用场景差异：
- 用整数位掩码存状态（如
status & 4 = 4表示有编辑权）→ 必须用整型字段+自定义逻辑或bool_and((status & 4) 0) - 用独立布尔列表达单一条件（如
is_verified）→ 直接BOOL_AND(is_verified)，无歧义
性能上，BOOL_AND能利用B-tree索引加速过滤（例如WHERE is_verified = true），而位运算字段无法直接走布尔索引。
什么时候BOOL_AND会变慢？
它本身极轻量，但实际性能取决于上游数据是否可下推过滤：
- 没建索引的布尔列 + 大表 +
GROUP BY→ 全表扫描不可避免 - 用了
BOOL_AND(CASE WHEN ... THEN true ELSE false END)嵌套表达式 → 可能阻止优化器下推条件 - 配合
DISTINCT或ORDER BY聚合 → 触发排序或去重，开销陡增
一个容易被忽略的点：BOOL_AND不能并行（截至PostgreSQL 16），如果分组量极大、单组数据极多，它仍是串行执行——这时得考虑是否真需要“全组一致为true”，还是改用NOT EXISTS (SELECT 1 FROM ... WHERE NOT flag)这类反向写法。
