优惠券减免金额不能直接按订单分组求和，因同一张券可被多单共用，订单表中discount_amount是单笔实际扣减额而非面值；需从订单粒度反向聚合至券维度，并校验字段是否为空或类型是否正确。
优惠券减免金额不能直接按订单分组求和？
因为一张优惠券可能被多个订单共用（比如满减券、店铺券），而订单表里通常只存 coupon_id 和 discount_amount，这个 discount_amount 是该订单实际使用的减免额，不是券的总面值。所以直接 GROUP BY order_id 求和没问题，但想回溯“这张券总共摊到多少订单上、各摊了多少”，就得从订单粒度反向聚合到券维度——而且得确认数据里是否记录了每单实际扣减额。
常见错误现象：SUM(discount_amount) OVER (PARTITION BY coupon_id) 算出来远小于券面值，或者为 0——大概率是 discount_amount 字段为空、为 NULL，或部分订单没走券（但字段仍留空）。
- 先检查：用
SELECT coupon_id, COUNT(*), COUNT(discount_amount), SUM(discount_amount) FROM orders WHERE coupon_id IS NOT NULL GROUP BY coupon_id LIMIT 5看空值比例 - 若
discount_amount经常为空，别盲目补 0；要查业务逻辑——是未使用？还是异步结算导致延迟写入？ - MySQL 8.0+ / PostgreSQL / SQL Server 支持窗口函数，但 SQLite 不支持
OVER，得用关联子查询替代
如何把单张优惠券的总减免额公平分摊到各订单？
真实场景中，“公平分摊”往往不等于“平均分”。比如一张满 300 减 50 的券，被两单分别用了 30 和 20，那它实际就是按订单实付比例动态扣减的。数据库里一般已存 discount_amount，你只需确保它准确——而不是在 SQL 里重新算。
但如果原始表只存了 coupon_id 和 coupon_face_value（面值），没存实际扣减额，那就必须结合订单金额推算。此时分摊逻辑必须和业务系统一致，否则对不上账：
- 最常见规则：按订单实付金额占所有同券订单总实付金额的比例分摊面值
（即：某单分摊 =coupon_face_value * order_paid_amount / SUM(order_paid_amount) OVER (PARTITION BY coupon_id)） - 注意：要排除
order_status IN ('cancelled', 'closed')的订单，否则分母失真 - 如果某券只被一单使用，分摊结果应等于面值，但浮点计算可能有微小误差，建议用
ROUND(..., 2)
分摊后怎么验证数据一致性？
分摊不是终点，核对才是关键。最容易被忽略的是时间范围错位：优惠券有效期、订单创建时间、支付完成时间、核销时间，四者可能跨天甚至跨月。用错时间字段会导致漏单或重复。
- 核对基准：以
coupon_used_at（核销时间）为准，而不是order_created_at - 写验证 SQL 时，先取一个典型
coupon_id，手动加总它的所有分摊值，再和业务系统导出的该券总核销额比对 - 警惕隐式类型转换：如果
discount_amount是VARCHAR类型，SUM()会静默失败或返回 0，务必用CAST(discount_amount AS DECIMAL(10,2)) - 大表慎用全量窗口函数，
PARTITION BY coupon_id在券种类少、订单多时性能尚可；若券数超百万，考虑加WHERE coupon_id IN (...)先过滤
订单表没存优惠券明细，只有订单主表怎么办？
很多老系统把优惠券逻辑放在应用层，订单主表只记最终实付金额，不存 coupon_id 或 discount_amount。这时候 SQL 层无法还原分摊，硬做只会引入猜测性逻辑。
必须确认是否存在独立的 coupon_usage 明细表，或交易流水表（transaction_log）里带券信息。如果没有，就不是 SQL 能解决的问题——得推动补日志或改写入逻辑。
- 临时方案：查应用日志或埋点数据，导出
order_id + coupon_id + actual_discount映射表，再 LEFT JOIN 回订单表 - 长期方案：在订单创建/支付成功事件中，强制写入
order_coupon_detail子表，字段至少含order_id、coupon_id、used_at、discount_amount - 千万别用“订单金额差额 = 优惠券减免”这种倒推方式，因为可能叠加红包、积分、运费券等其他减免项
分摊本身不难，难的是搞清每一笔 discount_amount 是谁写的、什么时候写的、依据什么规则算的。字段来源不清，SQL 写得再漂亮也对不上业务账。
