news 2026/5/1 7:23:58

GROUP BY进阶用法

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
GROUP BY进阶用法

问题重新:
sql语句中使用了GROUP BY wf_cur.REQUESTID, wf_cur.NODEID,为什么还会出用两行相同REQUESTID的记录呢,GROUP BY不就是拿某个字段来分组吗?

GROUP BY 是按你指定的字段组合进行分组的,不是按单个字段。

你的例子:

sql

GROUP BY wf_cur.REQUESTID, wf_cur.NODEID

这意味着:只有 REQUESTID 和 NODEID 都相同的记录才会被分到同一组

实际示例

假设原始数据:

text

REQUESTID NODEID USERID LASTNAME 1001 10 1 张三 1001 10 2 李四 <- 同一组(REQUESTID和NODEID都相同) 1001 20 3 王五 <- 不同组(NODEID不同) 1001 20 4 赵六 <- 同一组 1002 10 5 钱七 <- 不同组(REQUESTID不同)

分组结果:

  1. 组1:REQUESTID=1001, NODEID=10

    • 包含:张三、李四
    • GROUP_CONCAT结果:"张三, 李四"
  2. 组2:REQUESTID=1001, NODEID=20

    • 包含:王五、赵六
    • GROUP_CONCAT结果:"王五, 赵六"
  3. 组3:REQUESTID=1002, NODEID=10

    • 包含:钱七
    • GROUP_CONCAT结果:"钱七"

为什么会出现多行相同REQUESTID?

因为同一个REQUESTID可能有不同的NODEID!

在你的工作流系统中:

  • 一个流程(REQUESTID)会经过多个节点(NODEID)
  • 每个节点可能有不同的处理人
  • 所以同一个REQUESTID会出现在多个不同的节点中

你的数据示例:

text

REQUESTID NODEID 处理人 303364 371 何永刚 303364 372 何永刚, 谢雨芯 <- 节点372 303364 374 韦丹妮, 谢雨芯 <- 节点374(不同节点!) 303364 377 李华妹 <- 节点377(不同节点!)

GROUP BY REQUESTID, NODEID 后,每个(REQUESTID, NODEID)组合成为一行:

text

REQUESTID NODEID names 303364 371 何永刚 303364 372 何永刚, 谢雨芯 303364 374 韦丹妮, 谢雨芯 303364 377 李华妹

对比不同的GROUP BY方式

1. 按REQUESTID和NODEID分组(你的方式)

sql

GROUP BY REQUESTID, NODEID

结果:一个REQUESTID在不同节点会有多行记录

2. 只按REQUESTID分组

sql

GROUP BY REQUESTID

结果:一个REQUESTID只有一行记录,合并所有节点的人员

text

REQUESTID names 303364 何永刚, 何永刚, 谢雨芯, 谢雨芯, 韦丹妮, 李华妹...

3. 只按NODEID分组

sql

GROUP BY NODEID

结果:同一个节点来自不同流程的人员合并

text

NODEID names 372 何永刚(303364), 谢雨芯(303364), 张三(其他流程), 李四(其他流程)...

验证SQL

运行这个来查看实际的分组情况:

sql

-- 查看每个REQUESTID有多少个不同的NODEID SELECT REQUESTID, COUNT(DISTINCT NODEID) AS node_count, GROUP_CONCAT(DISTINCT NODEID ORDER BY NODEID) AS node_list, COUNT(DISTINCT USERID) AS user_count FROM workflow_currentoperator WHERE ISREMARK IN (0, 4) AND REQUESTID IN ('303364', '303365', '303366') -- 你的示例REQUESTID GROUP BY REQUESTID ORDER BY REQUESTID;

根据需求选择正确的GROUP BY

场景1:想要每个流程每个节点的处理人列表(你现在的需求)

sql

-- 正确:显示流程在每个节点上的处理人 SELECT REQUESTID, NODEID, GROUP_CONCAT(DISTINCT LASTNAME ORDER BY LASTNAME SEPARATOR ', ') AS node_handlers FROM workflow_currentoperator wf_cur INNER JOIN hrmresource zper ON wf_cur.USERID = zper.ID WHERE wf_cur.ISREMARK IN (0, 4) GROUP BY REQUESTID, NODEID;

场景2:想要每个流程的所有处理人(合并所有节点)

sql

-- 合并流程的所有处理人(不管在哪个节点) SELECT REQUESTID, GROUP_CONCAT(DISTINCT LASTNAME ORDER BY LASTNAME SEPARATOR ', ') AS all_handlers, COUNT(DISTINCT NODEID) AS total_nodes FROM workflow_currentoperator wf_cur INNER JOIN hrmresource zper ON wf_cur.USERID = zper.ID WHERE wf_cur.ISREMARK IN (0, 4) GROUP BY REQUESTID;

场景3:想要每个节点的所有处理人(合并所有流程)

sql

-- 查看每个节点有哪些人在处理(来自不同流程) SELECT NODEID, GROUP_CONCAT( DISTINCT CONCAT(LASTNAME, '(', REQUESTID, ')') ORDER BY LASTNAME SEPARATOR ', ' ) AS handlers_by_process, COUNT(DISTINCT REQUESTID) AS process_count FROM workflow_currentoperator wf_cur INNER JOIN hrmresource zper ON wf_cur.USERID = zper.ID WHERE wf_cur.ISREMARK IN (0, 4) GROUP BY NODEID;

总结

GROUP BY REQUESTID, NODEID 的结果是正常的!

  • 同一个REQUESTID + 不同的NODEID = 不同的分组
  • 这反映了工作流的真实情况:一个流程会经过多个节点
  • 每个节点可能有不同的处理人

如果你想要每个REQUESTID只显示一行,应该用GROUP BY REQUESTID
但根据你的数据,同一个REQUESTID在不同节点确实有不同的处理人,所以显示多行是正确的。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/4/26 17:01:07

基于springboot百度公司工作报告管理系统

基于Spring Boot的百度公司工作报告管理系统是一个集成了多种功能的企业级应用&#xff0c;旨在提高百度公司内部工作报告的管理效率和决策支持。以下是对该系统的详细介绍&#xff1a; 一、系统概述 该系统采用Spring Boot框架构建&#xff0c;结合MySQL数据库和Vue.js前端框架…

作者头像 李华
网站建设 2026/5/1 8:36:43

【基于模型的强化学习】#1 引论:Dyna架构

基于模型的强化学习 环境的模型&#xff08;Model&#xff09;是一个智能体可以用来预测环境对其动作的反应的任何事物。给定一个状态和一个动作&#xff0c;模型能产生后继状态和下一个收益的预测作为环境的反应结果。根据是否有模型参与&#xff0c;强化学习算法可分为基于模…

作者头像 李华
网站建设 2026/5/1 6:55:26

为Shopify店铺带来源源不断的流量:一份从零开始的SEO实操指南

Shopify 会自动处理技术性 SEO 基础工作&#xff0c;但出现在搜索引擎中仍然需要手动优化。 本指南将带您一步步优化您的Shopify商店以适应搜索引擎。 你将学习Shopify自动管理哪些SEO任务&#xff0c;哪些需要你关注&#xff0c;以及如何优先处理快速赢得带来流量的任务。 到最…

作者头像 李华
网站建设 2026/5/1 6:54:00

【MongoDB实战】6.3 索引优化实战:慢查询解决(补充)

文章目录 6.3 索引优化实战:慢查询解决 6.3.1 识别慢查询:explain()方法深度解析 核心概念 实操步骤1:准备测试数据集 实操步骤2:执行慢查询并分析执行计划 执行结果解读(未加索引) 6.3.2 优化案例:慢查询索引优化实战 核心优化思路 实操步骤1:创建复合索引 索引列表输…

作者头像 李华
网站建设 2026/5/1 9:42:31

Cordova与OpenHarmony换盆记录管理

欢迎大家加入开源鸿蒙跨平台开发者社区&#xff0c;一起共建开源鸿蒙跨平台生态。 换盆管理系统概述 换盆是植物生长过程中的重要环节&#xff0c;它为植物提供更多的生长空间和新鲜的土壤。在Cordova框架与OpenHarmony系统的结合下&#xff0c;我们需要实现一个完整的换盆记录…

作者头像 李华