GROUP BY配合SUM()是购物车合并结算的核心，按user_id等维度分组后对price×quantity求和，需确保分组键唯一、过滤状态用WHERE而非CASE、金额字段必须为DECIMAL类型。
GROUP BY 配合 SUM() 是合并结算的核心
购物车合并结算的本质，是把同一用户、同一订单或同一会话下的多条商品记录，按业务维度（如 user_id 或 cart_session_id）归组，再对金额类字段（如 price × quantity）求和。直接用 SUM(price * quantity) 而不是先算出每行小计再 SUM，能避免浮点误差累积，也更高效。
常见错误是漏写 GROUP BY，导致全表聚合成一行，丢失用户粒度；或者误把非聚合字段（如 product_name）放在 SELECT 中却不参与分组，触发 SQL 错误（MySQL 5.7+ 默认报错，PostgreSQL 始终报错）。
- 必须确保分组键唯一标识你要合并的“结算单元”，比如按
user_id合并当前未提交的购物车，就别用order_id（此时可能为空） - 若需同时显示用户名，得通过 JOIN 关联用户表，不能指望在购物车表里直接 SELECT
username后 GROUP BYuser_id - 注意 NULL 处理：
SUM()会自动忽略 NULL 值，但price * quantity若任一为 NULL，结果就是 NULL——建议用COALESCE(price, 0) * COALESCE(quantity, 0)
需要区分已结算/未结算状态？用 WHERE 预过滤比 CASE 更清晰
合并统计通常只针对“待支付”购物车项。与其在聚合内用 CASE WHEN status = 'pending' THEN price * quantity ELSE 0 END 再 SUM，不如先用 WHERE status = 'pending' 过滤。前者逻辑绕、可读性差，且无法利用 status 字段上的索引加速查询。
典型场景：前端点击“去结算”时，后端执行一次实时统计，此时必须排除已失效（status = 'expired'）、已下单（status = 'ordered'）的行。
- WHERE 过滤发生在聚合前，减少扫描行数，性能更好
- 如果真要跨状态对比（比如“待结算金额 vs 已取消金额”），才考虑
SUM(CASE WHEN ...)，但这是报表需求，不是结算动作本身 - 别在 WHERE 中写
status != 'ordered'——语义不清，且未来加新状态（如'refunded'）易漏判
MySQL 8.0+ 或 PostgreSQL 可用窗口函数补全明细信息
纯聚合会丢失原始商品明细，但结算页常需同时展示“合计金额”和“含哪些商品”。这时不用查两次，用窗口函数即可：
SELECT user_id, product_name, price, quantity, price * quantity AS item_total, SUM(price * quantity) OVER (PARTITION BY user_id) AS cart_total FROM cart_items WHERE status = 'pending';
这样每行仍保留商品信息，又附带了该用户的购物车总金额。注意 OVER (PARTITION BY ...) 不改变行数，适合前端渲染列表+汇总栏的场景。
- SQLite 不支持窗口函数，得用子查询或应用层二次计算
- 若只关心总额，别滥用窗口函数——增加解析开销，且部分 ORM 对 OVER 子句支持不稳定
- PARTITION BY 的字段必须和业务分组逻辑一致，比如按
cart_session_id分组就别写成PARTITION BY user_id，否则会混入其他会话数据
金额字段务必用 DECIMAL，别用 FLOAT 或 DOUBLE
这是最容易被跳过的坑。用 FLOAT 存价格，SUM() 后可能出现 99.99999999999999 这种结果，前端四舍五入掩盖问题，但对账时暴露无遗。所有涉及金钱的列（price、discount、total_amount）必须定义为 DECIMAL(10,2) 或更高精度。
- MySQL 中
DECIMAL(10,2)表示最多 10 位数字，小数点后固定 2 位；超出范围会截断或报错，反而是保护 - PostgreSQL 的
NUMERIC等价于DECIMAL，行为一致 - 即使 ORM 自动生成 schema，也要手动检查迁移文件里金额字段类型——很多模板默认用
float
合并结算看着只是加加减减，但分组逻辑、状态过滤、数值精度这三处稍有偏差，轻则金额对不上，重则结算单生成失败。尤其注意 GROUP BY 的粒度和 DECIMAL 类型，这两点在线上几乎没法事后补救。
