不可行，GROUP BY 后直接写 is_paid = true 虽在部分数据库能运行但存在 NULL 处理不一致、跨库兼容性差、逻辑模糊等风险，应改用显式 CASE WHEN 或原生字段分组。
GROUP BY 后直接写 is_paid = true 可行吗？
能跑通，但不推荐。PostgreSQL、MySQL 8.0+、SQL Server 允许在 GROUP BY 中直接使用布尔表达式（如 status = 'active'），但本质是隐式转成 0/1 分两组；旧版 MySQL（5.7 及之前）默认报错，除非关掉 ONLY_FULL_GROUP_BY。
更麻烦的是：表达式结果含 NULL 时（比如 status 字段本身为 NULL），status = 'active' 返回 UNKNOWN，被当作 0 或直接丢弃，不同数据库行为不一致。
-
SELECT is_paid, COUNT(*) FROM orders GROUP BY is_paid—— 安全，字段原生布尔/整型 -
SELECT status = 'active' AS flag, COUNT(*) FROM orders GROUP BY status = 'active'—— 风险高，status为NULL时分组逻辑模糊 - 别名不能用于
GROUP BY，GROUP BY flag会报错，必须重复写表达式
用 CASE WHEN 还是 SUM(IF()) 统计布尔条件数量？
跨库兼容选 CASE WHEN，MySQL 单独优化可选 SUM(IF())，但必须补全第三参数。
SUM(IF(status = 'active', 1, 0)) 在 MySQL 里有效，但 PostgreSQL、SQLite、SQL Server 全都不认 IF() 函数，硬写直接报错 function if(boolean, integer, integer) does not exist。
- 安全写法：
SUM(CASE WHEN status = 'active' THEN 1 ELSE 0 END) - 想跳过
NULL行：SUM(CASE WHEN status IS NOT NULL AND status = 'active' THEN 1 ELSE 0 END) - 只统计满足条件的行数（不关心 else）：
COUNT(CASE WHEN status = 'active' THEN 1 END)，更语义化 - 字段本身就是布尔类型（如 MySQL 的
TINYINT(1)）也别偷懒写SUM(active)，仍建议显式转换
WHERE 过滤和布尔分组的执行顺序怎么影响结果？
先 WHERE，再 GROUP BY。这意味着布尔分组只作用于已过滤后的数据集——这点极易被忽略，导致统计口径偏差。
例如要查「2024 年订单中已支付 / 未支付占比」，如果写成：
SELECT is_paid, COUNT(*) FROM orders GROUP BY is_paid WHERE created_at >= '2024-01-01';
语法就错了（WHERE 必须在 GROUP BY 前）。正确顺序是：
SELECT is_paid, COUNT(*) FROM orders WHERE created_at >= '2024-01-01' GROUP BY is_paid;
-
WHERE是行级筛选，减少参与分组的数据量，性能更好 - 若把条件挪到
HAVING（如HAVING MAX(created_at) >= '2024-01-01'），就变成对分组结果筛选，逻辑完全不同 - 涉及多表 JOIN 时，布尔条件放在 ON 还是 WHERE 也会影响结果集大小，需格外小心
需要三值逻辑（true/false/NULL）分组怎么办？
布尔表达式只有两个确定值，无法自然表达 NULL 状态；必须用 CASE WHEN 显式拆成三路。
比如按支付状态分“已支付”“未支付”“状态未知”，就不能依赖 is_paid = true 这种二值判断，得写：
SELECT<br> CASE<br> WHEN is_paid = true THEN 'paid'<br> WHEN is_paid = false THEN 'unpaid'<br> ELSE 'unknown'<br> END AS category,<br> COUNT(*)<br>FROM orders<br>GROUP BY<br> CASE<br> WHEN is_paid = true THEN 'paid'<br> WHEN is_paid = false THEN 'unpaid'<br> ELSE 'unknown'<br> END;
- 三个分支必须互斥且完备，
ELSE不能省，否则NULL被归入unknown但不显式声明，可读性差 - 分组字段和
SELECT中的CASE必须完全一致，不能用别名 - 若后续要加第四类（如 ‘pending’），
CASE结构扩展自然，布尔表达式则需重写逻辑
真正麻烦的不是语法能不能写，而是 NULL 在布尔上下文中的三值逻辑行为——它会让 “真/假” 判断失效，而多数人写 SQL 时默认只考虑二值场景。
