GROUP BY布尔字段报错根本原因是SQL引擎要求分组列必须是确定性、可比较的标量类型，而布尔值在不同数据库中映射不一：PostgreSQL和SQL Server明确拒绝直接分组，MySQL虽允许但行为不稳定，SQLite结果不可靠；稳妥做法是用CASE WHEN或CAST转为字符串/整数再分组。
GROUP BY 布尔字段时为什么报错？
直接写 GROUP BY is_active 在某些数据库（比如 PostgreSQL）会报错，因为布尔类型不能直接参与分组——它不被视为“可排序”或“可哈希”的标准分组类型。MySQL 虽然允许，但行为不稳定（尤其在严格模式下），PostgreSQL 和 SQL Server 则明确拒绝。
根本原因不是“布尔不能分组”，而是多数 SQL 引擎要求分组列必须是确定性、可比较的标量类型，而布尔在底层可能映射为 TRUE/FALSE 或 1/0，不同引擎处理方式不一。
- PostgreSQL 报错：
ERROR: column "is_active" must appear in the GROUP BY clause or be used in an aggregate function - MySQL 5.7+ 严格模式下同样拒绝，除非显式转换
- SQLite 允许，但结果不可靠（
NULL布尔值行为模糊）
用 CASE WHEN 或 CAST 实现稳定分组
最稳妥的方式是把布尔转成字符串或整数再分组。两种主流写法：
CASE WHEN 更通用，兼容所有主流数据库：
SELECT CASE WHEN is_active THEN 'active' ELSE 'inactive' END AS status, COUNT(*) AS count FROM users GROUP BY CASE WHEN is_active THEN 'active' ELSE 'inactive' END;
CAST 更简洁，但注意数据库支持差异：
- PostgreSQL / SQL Server：支持
CAST(is_active AS TEXT)或CAST(is_active AS INT) - MySQL：可用
IF(is_active, 'Y', 'N')或CAST(is_active AS CHAR) - SQLite：用
CASE最安全，CAST对布尔支持弱
COUNT + 条件聚合替代 GROUP BY
如果只关心“真/假各多少条”，不用显式分组也能拿到结果，性能通常更好（单次扫描）：
SELECT COUNT(*) FILTER (WHERE is_active) AS active_count, COUNT(*) FILTER (WHERE NOT is_active) AS inactive_count, COUNT(*) FILTER (WHERE is_active IS NULL) AS null_count FROM users;
这是 PostgreSQL 9.4+ 的语法；其他数据库需改写：
- MySQL：用
SUM(IF(is_active, 1, 0)) - SQL Server：用
SUM(IIF(is_active = 1, 1, 0)) - SQLite：用
SUM(CASE WHEN is_active THEN 1 ELSE 0 END)
这种写法避免了分组开销，也天然处理 NULL 布尔值——很多业务场景里，NULL 表示“未设置”，需要单独统计。
WHERE 过滤后 COUNT(*) 不等于分组计数
新手常误以为 SELECT COUNT(*) FROM t WHERE is_active 就等价于分组中的 active_count，其实不然：
- 如果表里有
NULL值，WHERE is_active会过滤掉所有NULL（因为NULL = TRUE为UNKNOWN），但分组中NULL会自成一组（或被忽略，取决于写法） - 想精确对应分组结果，必须显式处理
NULL：比如WHERE is_active IS TRUE（PostgreSQL）或WHERE is_active = 1（MySQL） - 跨数据库迁移时，
WHERE is_active的语义差异最大——MySQL 当 1 处理，PostgreSQL 当TRUE处理，SQLite 可能全当 0
布尔字段的 NULL 状态永远比 TRUE/FALSE 更容易出问题，只要涉及分组或条件统计，先确认 is_active IS NULL 是否有数据，再决定怎么处理它。
