SQL如何按任务进度进行分组统计_自定义聚合逻辑-SQL-PHP中文网

应先桶化再分组：用floor(progress*10)将进度转为0–9整数桶，再case映射为可读标签；需where过滤null和超限值，并显式order by保证顺序。

sql如何按任务进度进行分组统计_自定义聚合逻辑

GROUP BY 遇到非标准分组：进度字段不是离散值怎么办

直接用 GROUP BY progress 会把 0.23、0.27、0.71 这类浮点进度值各自分一组，根本达不到“按进度段统计”的目的。必须先做桶化（binning），再聚合。

常见错误是写 GROUP BY ROUND(progress, 1)——看似合理，但 0.25 四舍五入成 0.3，0.24 变成 0.2，边界不一致，统计结果错位。

推荐用 FLOOR(progress * 10) 转成整数桶：0.0–0.099→0，0.1–0.199→1，…，0.9–0.999→9
再用 CASE WHEN 映射为可读标签，比如 CASE WHEN FLOOR(progress * 10) = 0 THEN '0-10%' …
别在 SELECT 里用别名参与 GROUP BY（MySQL 5.7 默认不支持，会报 Unknown column）

PostgreSQL / MySQL 8.0+ 的窗口函数替代方案：需要累计分布时别硬 GROUP

如果目标不是“每段多少条”，而是“进度 ≤30% 的任务占总数多少比例”，硬套 GROUP BY + COUNT(*) 再除总行数，既啰嗦又难维护。

更直接的做法是用窗口函数算累计占比：

SELECT
  FLOOR(progress * 10) AS bucket,
  COUNT(*) AS cnt,
  SUM(COUNT(*)) OVER (ORDER BY FLOOR(progress * 10)) * 1.0 / SUM(COUNT(*)) OVER () AS cum_pct
FROM tasks
GROUP BY bucket;

注意：SUM(COUNT(*)) OVER 是合法的，但 SQLite 不支持，MySQL 5.6 也不支持窗口函数——得降级用自连接或变量模拟。

WHERE 条件漏写导致进度范围失真：特别是 NULL 和 1.0 的处理

任务进度字段常有三种异常值：NULL（未开始）、1.0（已完成）、>1.0（脏数据）。直接 GROUP BY FLOOR(progress * 10) 会让 NULL 分进一组（各数据库行为不一），1.0 进第 10 桶（FLOOR(1.0 * 10) = 10），但你的分段可能只定义到 9（即 90–99%）。

务必加 WHERE progress IS NOT NULL AND progress BETWEEN 0 AND 1
若想单独统计已完成任务，显式加条件：OR progress = 1.0，再用 CASE 单独归类
发现 progress > 1.0 时，别默默截断——先查出这些记录，修复源头逻辑

聚合后排序混乱：GROUP BY 结果默认无序，别依赖执行顺序

很多人写完 GROUP BY FLOOR(progress * 10) 就以为输出自然按 0、1、2… 排列，实际完全可能乱序（尤其 PostgreSQL 并行查询下）。一旦后续接图表或导出，顺序错乱就难排查。

解决方法只有一个：显式 ORDER BY。

按数值桶排：ORDER BY FLOOR(progress * 10)
按业务语义排（如 “未开始”、“进行中”、“已完成”）：在 CASE 中给每个分支加排序权重，或用 ORDER BY FIELD()（MySQL） / ORDER BY POSITION()（PostgreSQL）
别省这行 ORDER BY —— 它不耗性能，但省了它，下游所有环节都得补救

进度分组真正的复杂点不在 SQL 语法，而在于业务定义是否清晰：0.0 算“未开始”还是“初始化中”？0.999 和 1.0 是否应归为同一状态？这些边界没对齐，SQL 写得再漂亮，统计口径也是错的。