因为多次COUNT()会触发多次全表扫描，而SUM(IF())在一次扫描中通过0/1累加完成多条件计数，更省I/O、更快、更可控；其核心是IF返回数值（如IF(status='active',1,0)），避免NULL干扰。
为什么用 SUM(IF()) 而不是多次 COUNT()？
因为 MySQL 对同一张表执行多次 COUNT()（比如分别统计 status = 'active'、'pending'、'closed'）会触发多次全表扫描，I/O 和 CPU 开销翻倍。而 SUM(IF()) 在一次扫描中完成所有状态计数，本质是把布尔判断转为 0/1 累加——更省、更快、更可控。
SUM(IF()) 的基本写法和常见错误
核心是让 IF() 返回数值（通常是 1 或 0），再由 SUM() 累加。容易出错的点集中在条件逻辑和空值处理：
-
IF(status = 'active', 1, 0)✅ 正确：显式补 0，避免 NULL 干扰求和 -
IF(status = 'active', 1)❌ 危险：当status为NULL或不匹配时返回NULL，整个SUM()仍能算，但语义模糊且易被误读 - 别在
IF()里写复杂表达式（如嵌套CASE），可读性陡降，MySQL 优化器也难做常量折叠 - 字段名和字面量必须严格区分大小写（取决于
collation），'Active'≠'active'
实际查询示例与参数差异
假设有一张订单表 orders，含字段 id、status（值为 'pending'、'shipped'、'delivered'、'cancelled'）：
SELECT SUM(IF(status = 'pending', 1, 0)) AS pending_count, SUM(IF(status = 'shipped', 1, 0)) AS shipped_count, SUM(IF(status = 'delivered', 1, 0)) AS delivered_count, SUM(IF(status = 'cancelled', 1, 0)) AS cancelled_count FROM orders;
注意：AS 别名只是便于读取，不影响执行；若需过滤时间范围，WHERE 必须加在 FROM 后，不能放在 SUM() 内部；如果还要统计总数，直接加 COUNT(*) 即可，它和 SUM(IF()) 共享同一趟扫描。
性能与兼容性要注意什么？
SUM(IF()) 在 MySQL 5.7+ 和 8.0 中行为一致，但有几点实际影响性能：
- 没有索引时，仍需全表扫描——所以该优化只对“不得不扫全表”的场景有效；有合适索引（如
INDEX(status)）时，COUNT()也可能走索引覆盖，此时差距缩小 - 如果状态值很多（比如 20+ 种），写 20 行
SUM(IF())不仅难维护，还可能触发 MySQL 的表达式长度限制（max_allowed_packet一般不卡，但tmp_table_size可能受影响） - 想动态适配状态列表？
SUM(IF())做不到，得换CASE WHEN+ 应用层拼接，或改用GROUP BY status+ 客户端 pivot
真正省事又健壮的做法，往往不是堆函数，而是先确认是否真需要单次扫描——比如加个复合索引，可能比改写 SQL 更有效。
