AVG(SUM(x))等聚合函数嵌套非法，因SQL标准禁止且语义不明；须用子查询或CTE先分组再聚合，如SELECT AVG(dept_total) FROM (SELECT department, SUM(sales) AS dept_total FROM orders GROUP BY department) AS t。
为什么 COUNT/SUM/AVG 一起用会报错“invalid use of group function”
直接写 COUNT(SUM(price)) 或 AVG(MAX(sales)) 是非法的——聚合函数不能嵌套调用，SQL 引擎无法确定先按什么粒度分组。动态大屏要同时展示「总订单数」「平均客单价」「最高单日销售额」，本质是不同聚合逻辑并行计算，不是嵌套。
实操建议：
- 用子查询或 CTE 分别算各指标，再
SELECT合并：每个子查询独立GROUP BY（或不GROUP BY），避免嵌套 - 若所有指标都基于同一维度（比如按天统计），统一
GROUP BY date，各聚合函数并列写在SELECT列表里 - 注意 NULL 处理：
COUNT(*)统计行数，COUNT(column)自动忽略 NULL；大屏上“0 订单”和“NULL”含义不同，别混用
如何让 KPI 指标支持时间范围动态切换（如近7天 / 上月 / YTD）
硬编码 WHERE order_date >= '2024-06-01' 会导致每次改 SQL，大屏没法配置化。关键不是写死日期，而是把时间条件参数化，由前端传入或从配置表读取。
实操建议：
- 用变量或参数占位符（MySQL 用
@start_date，PostgreSQL 用$1，ClickHouse 支持{start_date:Date}模板） - 时间计算逻辑尽量下推到 WHERE，别在 SELECT 里用
CASE WHEN判定周期——否则全表扫描，大屏加载慢 - 对“上月”这类相对周期，别依赖
DATE_SUB(CURDATE(), INTERVAL 1 MONTH)这种易出错写法；推荐用LAST_DAY(DATE_SUB(NOW(), INTERVAL 1 MONTH))+DATE_ADD(LAST_DAY(...), INTERVAL 1 DAY)精确算月初月末
多个 KPI 共享同一张明细表时，怎样避免重复扫描拖慢大屏响应
如果每个 KPI 都单独查一次 orders 表（比如一个查 COUNT，一个查 SUM，一个查 DISTINCT user_id），IO 和计算开销翻三倍，尤其数据量过千万后，接口超时是常态。
实操建议：
- 用单次扫描 + 条件聚合：例如
SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END)算支付金额，COUNT(CASE WHEN status = 'paid' THEN 1 END)算支付单数 - 对需要去重的指标（如 UV），用
COUNT(DISTINCT user_id)，但注意 MySQL 5.7 及以前版本该操作不走索引，大数据量时考虑预计算宽表或 HyperLogLog 近似估算 - ClickHouse 用户优先用
uniqCombined(user_id)替代COUNT(DISTINCT)，性能提升明显
当 KPI 需要跨表关联（如订单+用户+商品）时，JOIN 顺序和过滤位置怎么选
写成 FROM orders JOIN users ON ... JOIN products ON ... WHERE users.level = 'vip' 很危险：如果 VIP 用户只占 1%，但先 JOIN 再 WHERE，中间结果集可能膨胀十倍，内存爆掉。
实操建议：
- 把高选择率的过滤条件尽量提前：先用子查询或 CTE 把
users表筛出 VIP 子集，再 JOIN，而不是最后 WHERE - 避免在 JOIN 条件里写函数，例如
ON DATE(o.created_at) = u.reg_date会让索引失效；改用范围比较：o.created_at >= u.reg_date AND o.created_at - 大屏统计通常不需要明细字段，SELECT 列只留聚合所需字段，减少网络传输和内存占用
动态大屏真正的复杂点不在语法，而在指标口径一致性——比如“活跃用户”在不同 KPI 里是否都排除了测试账号、是否都要求当日有支付行为。这些规则必须沉淀为视图或物化表，而不是每次 SQL 里手写 WHERE 条件。
