如何使用SQL实现分段统计：如按年龄段统计人数？

最常用且兼容性最好的年龄段分组统计方式是直接在SELECT中嵌套CASE WHEN并配合GROUP BY分组别名，需明确边界、处理NULL及异常值，并优先用WHERE预过滤提升性能。

用 CASE WHEN 实现年龄段分组统计

直接在 SELECT 中嵌套 CASE WHEN 是最常用、兼容性最好的方式，不需要依赖窗口函数或 CTE，MySQL、PostgreSQL、SQL Server 都能跑通。

常见错误是把年龄字段直接写进 GROUP BY，结果每岁一行，根本不是“分段”；或者漏写 ELSE，导致部分记录被丢弃（尤其当年龄为 NULL 或负值时）。

• 年龄段边界要明确闭合：比如 0-17 用 age < 18，18-25 用 age BETWEEN 18 AND 25，避免重叠或遗漏
• 必须配合 GROUP BY 分组别名（如 age_group），不能只写 CASE 表达式本身
• 示例语句：

SELECT   CASE     WHEN age < 18 THEN '未成年'    WHEN age BETWEEN 18 AND 35 THEN '青年'    WHEN age BETWEEN 36 AND 59 THEN '中年'    ELSE '老年'  END AS age_group,  COUNT(*) AS cntFROM usersGROUP BY age_group;

WHERE 过滤后再统计更高效

如果只关心某几个年龄段（比如只统计 18–45 岁用户），先用 WHERE 筛数据，再分组，比全表扫描 + CASE 判断快得多，尤其在大表上效果明显。

容易忽略的是：WHERE 无法替代 CASE 的分段逻辑——它只能排除，不能归类。比如你想同时看“18–25”和“26–35”两组人数，就不能只靠 WHERE age >= 18。

• 适合场景：报表固定只展示某几段，且对应字段有索引（如 age 列建了 B-tree 索引）
• 不要在 WHERE 里写函数，比如 WHERE FLOOR(age/10)*10 = 20，会失效索引
• 正确写法示例（查 18–45 岁各细分段）：

SELECT   CASE     WHEN age < 25 THEN '18-24'    WHEN age < 35 THEN '25-34'    ELSE '35-45'  END AS range,  COUNT(*) FROM users WHERE age BETWEEN 18 AND 45 GROUP BY range;

用 WITH RECURSIVE 构造连续分段（高级但少用）

当分段规则复杂、区间多（比如按 5 岁一档从 0 到 100），硬写几十个 WHEN 易出错且难维护，这时可考虑用递归 CTE 生成分段维度表再 LEFT JOIN。

注意：SQLite 和旧版 MySQL 不支持 WITH RECURSIVE；PostgreSQL 和较新 MySQL（8.0+）可用，但性能不一定比静态 CASE 好，仅适合动态配置场景。

• 关键点：递归终止条件必须明确（如 upper_bound <= 100），否则无限循环
• JOIN 时要用 ON u.age >= d.lower AND u.age < d.upper，注意开闭区间一致性
• 简单示意（非完整可执行）：

WITH RECURSIVE age_ranges AS (  SELECT 0 AS lower, 5 AS upper  UNION ALL  SELECT lower + 5, upper + 5 FROM age_ranges WHERE upper < 100)SELECT r.lower, r.upper, COUNT(u.id) FROM age_ranges rLEFT JOIN users u ON u.age >= r.lower AND u.age < r.upperGROUP BY r.lower, r.upper;

NULL 和异常值必须显式处理

真实数据里 age 字段常有 NULL、0、负数甚至超大值（如 999），这些默认不会进入任何 WHEN 分支，若没写 ELSE 就直接消失，导致总数对不上。

调试时发现统计总数变少，第一反应就该查 SELECT COUNT(*), COUNT(age) FROM users 是否相等——不等说明有 NULL 干扰。

• 推荐写法：所有 CASE 必带 ELSE '未知' OR NULL，并单独统计
• 若业务要求排除异常值，用 WHERE age > 0 AND age < 150 更清晰，别塞进 CASE
• 别依赖数据库自动类型转换：比如字符串型 '25' 和数值型 25 混用会导致 CASE 判断失效

实际写的时候，多数情况用第一个方案就够了；真正卡性能或要灵活配置才往上翻后面两个。分段逻辑一旦上线，改起来牵扯报表和下游，所以边界定义和 NULL 处理务必在 SQL 里写死，别指望应用层补。