group by后字段必须同时出现在select或聚合函数中，否则mysql 5.7+因only_full_group_by报错；动态拼sql时需严格对齐select与group by列表，禁用宽松模式，避免结果不可靠。
GROUP BY 后字段必须出现在 SELECT 或聚合函数里
这是动态分组最常卡住的地方：你拼接了 GROUP BY 字段，但 SELECT 里漏了对应列，或混用了非聚合字段和聚合函数。MySQL 5.7+ 默认开启 sql_mode=ONLY_FULL_GROUP_BY，直接报错 Expression #1 of SELECT list is not in GROUP BY clause。
实操建议：
- 动态拼 SQL 时，
SELECT列表和GROUP BY子句必须严格对齐——每个非聚合字段都要同时出现在两边 - 别依赖 MySQL 旧版本“宽松模式”，它会让结果不可靠（比如随机取某行的值）
- 如果前端传入的是分组维度数组
['region', 'product_type']，就用相同顺序生成SELECT region, product_type, SUM(sales)和GROUP BY region, product_type
用 CASE WHEN + 动态列名实现条件聚合
真正按需分组不只是换 GROUP BY 字段，还常要切换统计口径，比如“按月汇总” vs “按季度汇总”。硬写多个 SQL 维护成本高，用 CASE WHEN 拆解时间维度更灵活。
实操建议：
- 把时间粒度逻辑收进
SELECT，例如：SELECT SUM(sales), COUNT(*), CASE WHEN EXTRACT(MONTH FROM order_date) IN (1,2,3) THEN 'Q1' ... END AS quarter - 避免在
GROUP BY里嵌套复杂表达式（如DATE_FORMAT(order_date, '%Y-%m')），不同数据库对表达式索引支持不一，可能拖慢查询 - PostgreSQL 可用
GENERATE_SERIES补全缺失分组（如某月没数据），MySQL 得靠 LEFT JOIN 临时表，这点容易被忽略
WHERE 条件不能写在 HAVING 里替代过滤
动态报表常要支持“只看销售额 > 10w 的区域”，有人图省事把 WHERE sales > 100000 写成 HAVING SUM(sales) > 100000，结果查出空集或逻辑错乱。
实操建议：
-
WHERE过滤原始行，HAVING过滤分组后结果——两者语义完全不同，不能互换 - 动态参数如果是单值过滤（如
region = '华东'），必须走WHERE；如果是聚合后筛选（如SUM(sales) > 100000），才用HAVING - 拼接 SQL 时，把
WHERE条件和HAVING条件分开维护，避免混淆。尤其注意 NULL 值处理：WHERE region IS NOT NULL不等于HAVING COUNT(region) > 0
UNION ALL 比多次查询更可控，但要注意字段类型对齐
有些报表需要合并多张结构相似但来源不同的表（如分库分表的订单数据），用循环查再内存合并，不如一次 UNION ALL 靠谱。
实操建议：
- 所有
SELECT子句的字段数量、顺序、类型必须一致，否则报错UNION types text and integer cannot be matched - 显式转换类型，比如：
CAST(order_id AS BIGINT)统一数值精度，COALESCE(status, '')避免NULL和字符串混排导致隐式转换失败 - 别用
UNION（去重），动态报表通常不需要，且去重开销大；UNION ALL更快也更可预期
动态分组真正的难点不在语法，而在字段对齐和执行计划漂移——同一份 SQL 在不同参数下可能走全表扫描，也可能命中索引，得结合 EXPLAIN 看实际执行路径，而不是只信预想的逻辑。
