GROUP BY多字段顺序不影响聚合结果，但影响输出行序和可读性；需显式ORDER BY保证排序；跨区域成本须用加权平均（SUM(cost)/SUM(quantity)）而非AVG(cost)。
GROUP BY 多字段时顺序影响结果吗？
不影响聚合逻辑，但影响结果排序和可读性。数据库不会按你写的字段顺序自动排序，除非显式加 ORDER BY。实际中常因忽略排序，导致看错“哪个维度是主分组”，尤其在跨区域+运输方式+时间粒度混合时。
-
GROUP BY region, transport_mode, date_trunc('month', shipment_time)和GROUP BY transport_mode, region, date_trunc('month', shipment_time)产出的行数、值完全一致 - 但前者按区域优先排列，后者按运输方式优先——导出到 Excel 或对接 BI 时，顺序错位容易误读趋势
- PostgreSQL 中
date_trunc()返回 timestamp，别直接跟 string 类型的region混用，否则某些版本会隐式转成 text 再拼接，引发精度丢失（比如把 '2024-01-01' 截断成 '2024-01' 后又补了时区偏移）
跨区域成本要加权平均，不能直接 AVG(cost)
物流单量在不同区域差异极大，比如华东发 500 单、西北只发 12 单，若用 AVG(cost)，西北单次成本会被过度放大。真实业务需要的是「总成本 / 总单量」，即加权均值。
- 错误写法：
SELECT region, AVG(cost) FROM shipments GROUP BY region—— 忽略了单量权重 - 正确写法：
SELECT region, SUM(cost) / NULLIF(SUM(quantity), 0) AS avg_cost_per_order FROM shipments GROUP BY region -
NULLIF(SUM(quantity), 0)防止除零；部分数据库（如 MySQL）不支持NULLIF，得改用CASE WHEN SUM(quantity) = 0 THEN NULL ELSE SUM(cost)/SUM(quantity) END - 如果成本字段含空值（
NULL），SUM(cost)会自动跳过，但COUNT(*)不会，所以别用COUNT(cost)当分母
JOIN 区域表时，LEFT JOIN 还是 INNER JOIN？
取决于你是否要保留无地理信息的运单。生产环境里常有 region_code 为空或拼写错误的记录，用 INNER JOIN 会直接丢掉这些单——它们可能恰恰是成本异常的根源。
- 查全量分布：用
LEFT JOIN regions ON shipments.region_code = regions.code，然后用CASE WHEN regions.code IS NULL THEN 'UNKNOWN' ELSE regions.name END归类 - JOIN 字段类型要严格一致：如果
regions.code是CHAR(4)，而shipments.region_code是VARCHAR(10)，某些数据库（如 Oracle）会在 JOIN 前补空格，导致匹配失败 - 加索引：确保
shipments.region_code和regions.code都有 B-tree 索引，否则百万级运单 JOIN 会慢到超时
时间范围跨月/跨年时，GROUP BY 的陷阱
别用字符串截取来分月，比如 SUBSTR(CAST(shipment_time AS TEXT), 1, 7)。它看似能拿到 '2024-01'，但无法利用索引，且在时区切换时出错（例如服务器在 UTC+8，但数据存的是 UTC 时间）。
- 安全做法：用数据库原生时间函数，PostgreSQL 用
DATE_TRUNC('month', shipment_time AT TIME ZONE 'Asia/Shanghai')，MySQL 用DATE_FORMAT(CONVERT_TZ(shipment_time, '+00:00', '+08:00'), '%Y-%m') - WHERE 条件必须和 GROUP BY 时间粒度对齐：如果按月聚合，WHERE 里别写
shipment_time >= '2024-01-15'，否则当月前半月数据被过滤，但后半月还在，导致分母失真 - 测试时务必查下原始数据里有没有未来时间（比如测试数据写成 '2099-12-31'），这类脏数据会让
DATE_TRUNC返回奇怪结果，甚至拖慢整个查询
