动态GROUP BY需白名单校验列名后拼接SQL或用CASE WHEN映射，禁用字符串硬拼防注入；MySQL用PREPARE+EXECUTE，PostgreSQL可传数组参数并以CASE WHEN动态生成分组表达式。
WHERE 条件动态时，GROUP BY 不能硬编码列名
直接写 GROUP BY col1, col2, col3 行不通——如果某些列在运行时可能不参与分组（比如用户勾选了“按地区分组”但没勾选“按日期分组”），硬编码会导致逻辑错误或 SQL 报错。核心思路是：把分组列名拼成字符串，再用动态 SQL 执行。
常见错误现象：ERROR: column "xxx" must appear in the GROUP BY clause or be used in an aggregate function，本质是 SELECT 和 GROUP BY 列不一致，而动态场景下这个不一致是预期的。
- PostgreSQL / SQL Server / Oracle 支持
EXECUTE或sp_executesql动态执行；MySQL 8.0+ 可用PREPARE + EXECUTE - 不要在应用层拼接 SQL 字符串后直接执行（易 SQL 注入），必须对列名白名单校验（如只允许
['region', 'category', 'status']） - 聚合函数如
COUNT(*)、SUM(amount)不受动态影响，但需确保它们不依赖被排除的分组列
用 JSON 或数组参数传递动态列（PostgreSQL 示例）
PostgreSQL 支持 jsonb 和 VARIADIC，可把要分组的列名传成数组，再用 jsonb_object_agg 或 string_to_array 拆解。比纯字符串拼接更安全。
示例：假设输入参数为 group_cols TEXT[] = ARRAY['region', 'category']：
SELECT (CASE WHEN 'region' = ANY($1) THEN region END) AS region, (CASE WHEN 'category' = ANY($1) THEN category END) AS category, COUNT(*) AS cnt, SUM(amount) AS total FROM sales WHERE status = 'active' GROUP BY (CASE WHEN 'region' = ANY($1) THEN region END), (CASE WHEN 'category' = ANY($1) THEN category END) HAVING COUNT(*) > 0;
注意：CASE WHEN 在 GROUP BY 中返回 NULL 时，会把所有该列为 NULL 的行归为一组——这符合“不参与分组”的语义，但需确认业务是否接受 NULL 分组值。
MySQL 8.0+ 动态 GROUP BY 的最小可行方案
MySQL 不支持数组参数，只能靠应用层拼接 SQL，但必须严格过滤列名。关键不是“怎么拼”，而是“怎么防注入”。
- 白名单校验必须在数据库外完成（如 Python 中
if col not in ['user_id', 'dept', 'month']: raise ValueError） - 拼接时用反引号包裹列名：
`{col}`，防止关键字冲突（如列名是order） - 避免用
CONCAT('GROUP BY ', @group_sql)直接拼，应先构造完整 SQL 字符串再PREPARE - 聚合字段别名不能动态，必须固定写死（如
COUNT(*) AS total），否则结果集结构不可预测
去重逻辑和分组聚合容易混淆的点
“多列去重分组聚合”听起来像先 DISTINCT 再 GROUP BY，但实际绝大多数场景不需要显式 DISTINCT——GROUP BY 本身已隐含去重语义。真正要小心的是：
- 业务上要求“同一组内某字段值唯一”，比如每组只取最新一条记录，这时得用
ROW_NUMBER() OVER (PARTITION BY ... ORDER BY updated_at DESC)配合子查询 - 如果原始数据有重复行且必须先剔除，才做聚合，那么必须
GROUP BY前套一层SELECT DISTINCT子查询（性能差，慎用） - NULL 值在 GROUP BY 中被视为相同值，但不同数据库对 NULL 的排序行为略有差异（如 MySQL 认为 NULL = NULL，Oracle 同样，但有些旧版本驱动可能表现不一）
最常被忽略的是：动态列组合导致分组粒度变化时，聚合结果的业务含义是否仍成立。比如加一个 user_id 进去，SUM(revenue) 还是“部门总营收”吗？这个问题不在 SQL 能力范围内，得靠上游逻辑兜底。
