AVG(order_amount) 不加 GROUP BY store_id 得到的是全表平均值而非各店铺单均消费；必须显式分组，且 SELECT 与 GROUP BY 字段需对齐，否则结果错误或报错。
AVG() 计算单均消费为什么结果不对？
直接用 AVG(order_amount) 得到的不是“每个店铺的单均消费”，而是全表所有订单的平均值——除非你加了 GROUP BY store_id。没分组，AVG() 就只返回一行聚合结果，和店铺无关。
- 常见错误现象：
SELECT store_id, AVG(order_amount)不报错但store_id值随机（MySQL 5.7+ 严格模式下直接报错Expression #1 of SELECT list is not in GROUP BY clause） - 必须显式写
GROUP BY store_id，否则 SQL 语义不成立 - 如果某店铺有 NULL 订单金额，
AVG()自动跳过它，不影响该店计算——这是正确行为，不是 bug
分组后怎么排除退款订单？
单均消费要反映真实销售能力，得把 status = 'refunded' 或 order_amount 的脏数据过滤掉，不能靠后期 WHERE 粗暴截断——那样会漏掉整个店铺（只要有一笔退款，整店就没了）。
- 用
HAVING不行：它是对分组后结果过滤，无法筛掉单条记录 - 必须在
GROUP BY前用WHERE过滤原始行：WHERE order_amount > 0 AND status != 'refunded' - 注意 NULL 安全：如果
status可能为 NULL，加AND status IS NOT NULL，避免意外丢数据
用 AVG() 还是 SUM()/COUNT()？结果一样吗？
数学上等价，但行为细节不同：当某店铺没有任何符合条件的订单时，AVG() 返回 NULL，而 SUM()/COUNT() 中 COUNT() 为 0，会导致除零错误（MySQL 返回 NULL，PostgreSQL 报错 division by zero）。
- 推荐统一用
AVG()：语义清晰、NULL 处理一致、数据库优化更成熟 - 如果非要手写
SUM(order_amount) / NULLIF(COUNT(*), 0)，记得套NULLIF防除零 - 性能无实质差异，优化器通常会把
AVG()重写为底层 SUM/COUNT
店铺名没进结果？别忘了 SELECT 和 GROUP BY 要对齐
想看 store_name 却只写了 SELECT store_name, AVG(order_amount) FROM orders GROUP BY store_id，这会报错或返回错乱数据——因为 GROUP BY 用的是 store_id，但 SELECT 列里混了非分组、非聚合字段。
- 要么改
GROUP BY store_id, store_name（推荐，语义明确） - 要么 JOIN 店铺表，在外层查
store_name，分组仍基于store_id - 别依赖 MySQL 的“功能”（如 sql_mode 关闭 strict_trans_tables），其他数据库不认这种写法
