邮件标题：20260908-技术评审-渠道营销底座-门店地址层新增二级渠道类型

邮件正文：

晓娜、建新：
已完成针对【门店地址层新增二级渠道类型】的技术评审，现将评审结论、风险判断及后续执行安排同步如下，便于各方对齐认知并落实执行。

项目名称： 渠道营销底座
评审时间： 2026/09/08
参与评审人： 李明非、郝梓斐、余勇军、张建利、吴南林、王建朝、马奇、刘晓娜、吕杰
评审结果： 通过

一、技术方案背景

• 业务场景：液奶事业部新活动（门店售卖激励，PRD 5.2）在创建活动时需要按门店二级渠道类型做筛选与约束，主数据已在门店地址视图/接口中新增二级渠道类型编码与名称两个字段，底座需在链路中逐层透传并落库，支撑活动配置筛选门店、活动抽奖校验等场景。

二、技术方案要点

• 整体流程：主数据（视图/接口）推送 → ShopAddressRelay 接收新增字段 → SyncShopAddressServiceImpl 转 ShopAddressDTO → SyncMasterServiveImpl 转落库实体 ShopAddress → shop_address 表新增 channel_sub_type / channel_sub_type_name 两列 → 因门店数量超千万无法指定更新，采用主数据全量推送初始化 → 数据清洗完成后再添加联合索引。

三、决议事项

• 渠道营销底座与老营销活动两个项目下各维护一份技术方案，分别写明各自应用场景与影响范围，底座侧用于创建活动时按二级渠道类型筛选门店、活动抽奖时校验，需要在营销活动中心（液奶）项目下补充独立的技术方案。由郝梓斐负责。
• 索引必须等全量数据推送清洗完成后再添加，避免"边推数边写索引"导致数据库压力翻倍，索引设置合理性需与 DBA 分析确认后再执行，由郝梓斐负责。
• 加索引前组织专项沟通会，拉 云平台DBA（宗杨）共同评估执行方案与锁表影响（历史上出现过加索引导致数据库故障），评估通过后再执行，由李明非负责。
• 新增字段长度（当前 varchar(100)）需与主数据侧确认实际长度后再确定，不要自行预设，由郝梓斐负责。

四、风险提示

• 门店数据量 1600 万+，全量推送叠加加索引期间数据库压力大且可能锁表，存在影响线上业务的风险（历史上出现过加索引导致数据库故障）。
• 索引区分度存疑：二级渠道类型约 200 种且分布不均，存在加了索引但不生效或效果不佳的风险，需实测验证后再上生产。
• 测试环境数据不全（仅几万条、字段尚未启用），索引效果无法在测试环境充分验证，需接入生产真实数据后再确定索引方案。

五、方案地址

技术方案：https://yldc.coding.yili.com/p/sip-marketing-portal/wiki/475