MySQL GROUP_CONCAT配合GROUP BY查询报1111/1142错误求解

两个报错的本质是聚合层级逻辑写混了：

• 1111 聚合函数非法使用：你在同一层查询里同时嵌套使用了SUM()（分组级聚合）和GROUP_CONCAT()（结果集级聚合）两个不同层级的聚合函数，还直接按商品ID分组，MySQL无法解析同一层级下的嵌套聚合逻辑，直接抛出错误。
• 1142 子查询返回多行：去掉SUM()之后，子查询按商品ID分组，每个工单号会返回对应N条商品记录（N为工单关联的商品种类数），但SELECT后面跟的标量子查询要求必须返回单行单列结果，自然触发报错。

核心思路是拆成两层聚合：第一层先按「工单ID+商品ID」维度分组，计算每个工单下每个商品的总数量、总金额；第二层再把同一工单下的所有商品计算结果拼接成要求的字符串格式，完全匹配业务约束：

SELECT
    tt.*,
    (
        SELECT GROUP_CONCAT(
            CONCAT(
                "[",
                it.label_item,
                ", qty: ",
                ti_agg.total_qty,
                ", total: ",
                ti_agg.total_amount,
                "]"
            ) SEPARATOR ', '
        )
        FROM (
            SELECT
                id_item,
                SUM(qty_item) AS total_qty,
                SUM(qty_item * pu_item) AS total_amount
            FROM tickets_items
            WHERE id_ticket = tt.id_ticket
            GROUP BY id_item
        ) ti_agg
        INNER JOIN items_table it ON it.id_item = ti_agg.id_item
    ) AS items
FROM tickets_table tt;

执行后返回的结果和给出的预期结果完全一致。

• 完全兼容业务约束：所有数量、金额计算都从tickets_items明细累加，即使同一工单下同商品单价不同也不会算错；主查询始终以tickets_table为核心表，后续要关联支付记录、其他业务表时直接在主查询层加JOIN逻辑即可，不会影响商品字段的聚合结果。
• 长度兼容：如果业务中单个工单关联的商品很多，GROUP_CONCAT返回结果可能被截断，可以提前调大参数：SET SESSION group_concat_max_len = 102400;（将当前会话的聚合结果最大长度设为100KB，可根据实际需求调整数值）。

内容的提问来源于stack exchange，提问作者scomer51