邮件标题：20260909-技术评审-营销活动中心-消费者中奖明细表产品信息修复
邮件正文：
晓娜、建新：
已完成针对【消费者中奖明细表产品信息修复】的技术评审，现将评审结论、风险判断及后续执行安排同步如下，便于各方对齐认知并落实执行。
项目名称： 营销活动中心
评审时间： 2026/09/09
参与评审人： 马奇、李明非、邱毅、邢健、张建利、孙传熙、朱鸿君、曹旭、张喜、潘玉平、王建朝
评审结果： 有条件通过，需按要求优化后再实施方案。
一、技术方案背景
- 业务场景：806 服务发版（2026-08-06 上线）后，消费者扫码核销中奖链路向
redemption_his（消费者中奖明细/核销记录明细）写入数据时，部分记录因未取到产品主数据（data 服务异常）导致brand_name、product_no、product_name、product_date四个字段为空；本次仅对历史存量 358 条做数据修复，当前code_info中这些追溯码已能查到正确产品信息，可用于回填。
二、技术方案要点
- 整体流程：定位
redemption_his中product_no为空、且create_time >= 2026-08-06、排除"客诉码"的 358 条历史存量 → 按trace_code匹配 MongoDBcode_info（seqnum = trace_code）取产品主数据 → 回填brand_name/product_no/product_name/product_date四列并置update_time = NOW()→ 逐条 UPDATE 执行；执行前先建备份表redemption_his_bak_20260910。
三、决议事项
- SQL 脚本中需要有明确的分区字段，避免全表扫描。
- SQL 脚本中 Where 条件存在多个冗余条件，需取去掉。
- 整理流程调整为先检索出异常数据保存到临时表，再从临时表检索更新原表。有效避免大量的全表扫描操作，提升处理效率，提升系统稳定性。
四、风险提示
- 客诉码行无对应
code_info，已排除不修复，此类行产品字段仍为空属预期，需与业务方共识。 - 根因未纳入本次方案：核销中奖链路在 data 服务异常时未取到产品主数据即写入空字段，同类异常再次发生时仍会产生空字段数据。