2026-08-11 工作日志
项目进展与数据一致性同步会
本次会议同步了各项目进展，重点讨论了数据一致性问题及解决方案，并明确了后续工作安排。
小结
1. 各项目及需求进展
- B 端出货的营销助手业务已获同意，待签字流程完成后即可发版。
- 移动端看板需求已基本确定，计划本周内组织评审。
- 应用中心的"盘点任务"和"会员积分"功能将整合进下一个版本，需求已更新。
2. 数据一致性问题及解决方案
- 智慧门店：已通过切换数据查询服务的方式解决历史数据差异问题。
- 云商系统：已修复因主数据推送后未更新导致的数据不一致问题。
- 营销活动中心：将处理高邮问题，以解决数据一致性问题。
- 数据血缘关系：将由余建新团队在本周内梳理并排期解决。
3. 其他问题跟进
- data 数据库性能：发现其在每日 8:00-9:30 时段存在性能瓶颈，已安排张喜进行排查。
- 技术方案要求：提出技术方案需与产品方案对齐，特别是要回应产品方案中的关键点，并将新老接口兼容等问题前置到方案评审中。
待办
1. 需求更新与发布
- 刘晓娜负责将应用中心"盘点任务"和"会员积分"的需求拆分细化后，在群里通知并等待统一发布。
2. 数据问题跟进
- 邢健负责今日内完成数据修复后的质量核对，并确认是否可以使用。
- 余建新负责协调电子围栏团队，跟进其功能和接口问题的排期。
- 余建新负责本周内梳理并排期解决数据血缘关系问题。
3. 数据库性能问题
- 张喜负责跟进 data 数据库性能瓶颈的定位和解决。
4. 问题记录
- 张建利负责将 data 数据库性能问题记录在案。
"奶酪"活动测试范围评审会
会议讨论了"奶酪"活动的测试范围，明确了流向查证、盘点及作弊明细等报表的配置规则、数据权限及测试要点。
小结
1. 底座及系统配置
- 底座相关功能将使用"奶酪"的数据进行替换和回归验证。
- 系统配置将只保留计费、营销活动中心和基础底座三块内容，移除卡券等相关配置。
2. 压测范围
- 活动侧的抽奖、流向查证、盘点等对外接口需要进行专项压测。
- 底座的性能瓶颈问题已知，将通过架构升级解决，届时将进行专项压测。
3. 流向查证规则配置
- 查证字段配置：系统将预置两条内置规则（消费者、非消费者），允许编辑字段的显示/隐藏开关，但不支持修改规则名称、优先级、所属事业部等其他字段。
- 异常判断规则：将预置两条内置规则（经销商围栏、判断门店和仓库），仅提供查看功能，不支持新增、编辑或禁用。
4. 报表功能与数据权限
- 查证明细表与流向异常明细表：将进行完整的查询、组合筛选、导出、数据权限及列控验证。报表中的"扫码工具"等字段需补充相应的字段说明。
- 作弊明细表：将进行查询、展示及数据权限验证。需与业务方确认作弊的详细级别（如中转箱、袋子等）。
- 盘点相关报表：盘点明细表和盘点统计表将进行类似报表的全面测试。盘点统计表的汇总逻辑复杂，其聚合规则需线下与开发确认并补充到 PRD 中。
待办
1. PRD 文档完善
- 在 PRD 中明确"查证字段配置"和"异常判断规则"页面的内置规则详情，如规则名称、编码、优先级等。 — @吴南林
- 在 PRD 中补充"盘点统计表"的数据聚合逻辑说明。 — @吴南林
- 在 PRD 中明确"作弊明细表"各字段的必传与非必传属性。 — @吴南林
2. 测试用例与页面调整
- 根据会议结论，更新"查证字段配置"页面的测试用例，移除"创建开始/结束时间"等不必要的查询条件，并移除"启用/禁用"功能。 — @陈晨
- 在"查证明细表"和"流向异常明细表"的用例中，将导出数据量上限从 50 万调整为 300 万。 — @陈晨
- 在"作弊明细表"的用例中，根据 PRD 补充必传/非必传字段的验证。 — @陈晨
- 在"盘点统计表"的用例中，根据 PRD 补充汇总逻辑的验证。 — @陈晨
3. 技术与开发确认
- 与开发同学确认"盘点统计表"汇总逻辑的具体实现方式。 — @吴南林
- 与 SFA 团队确认"作弊明细表"中涉及的码的级别及具体表现形式。 — @吴南林
电子围栏 CPU 过高问题及数据修复方案会
会议讨论了电子围栏功能引发的 CPU 过高问题及解决方案，并审阅了人员编码数据修复方案。
小结
1. 电子围栏 CPU 过高问题及解决方案
- 问题根源：新上线的电子围栏功能，在扫码核验串货规则时，因未命中索引导致数据库查询缓慢。当大量并发请求（如批量出货单）集中到来时，瞬时的高并发请求将数据库 CPU 瞬间打满至 100%。
- 临时解决方案：在调用方（报表处理服务）增加 Redis 临时缓存。当首次查询数据库时，将结果存入 Redis；后续相同查询则直接从 Redis 获取，从而大幅降低对数据库的瞬时压力。
- 长期优化探讨：会议深入探讨了业务逻辑的优化。当前方案是在订单落库后，批量地对单笔订单下的所有商品码进行串货校验，这在技术上造成了"堰塞湖"效应。与会者讨论了改为在扫码时就进行即时校验的可能性，但这需要进一步研究现有业务逻辑和历史需求（PRD）来确认其可行性。
2. 销售区域查询逻辑分析
- 查询方式：用于串货校验的销售区域查询逻辑，存在技术实现上的问题。为兼容旧版逻辑，查询时使用 LIKE 模糊匹配，而非精确的 EQ 匹配。
- 性能影响：LIKE 查询在数据量大时效率较低，且会匹配到所有父级区域，导致不必要的数据扫描，是造成性能瓶颈的原因之一。
3. 人员编码数据修复方案
- 问题背景：在 806 版本中，因终端传参错误，将"员工编码"误传为"手机号"，导致约 300 多条数据在"查证明细表"中出现异常。
- 解决方案：提供了一套完整的修复方案。通过预检 SQL 定位异常数据，使用 UPDATE 语句将错误的手机号数据修正为正确的员工编码，并设置了联合条件确保更新的准确性。
待办
1. 电子围栏 CPU 过高问题优化
- 在调用方增加 Redis 缓存，作为临时解决方案，以缓解数据库瞬时高并发压力。 — @宋洋
- 会后梳理串货校验的整体业务流程，并制作流程图，以便评估长期优化方案的可行性。 — @宋洋 @王建朝
- 评估将 LIKE 查询优化为 EQ 精确查询的可行性，并补充相应代码。 — @郝梓斐
2. 销售区域查询逻辑优化
- 评估并移除已无业务调用的旧版 SQL（如第 7.5 部分），以减少不必要的代码负担。 — @郝梓斐
3. 异常数据修复
- 执行人员编码修复方案，将 300 余条异常数据中的手机号修正为正确的员工编码。 — @潘玉平
积分活动技术方案评审会
本次会议评审了积分活动的技术方案，重点讨论了激励规则、排他性校验和盘点任务等功能，并针对技术选型进行了深入沟通。
小结
1. 积分活动激励规则技术方案
- 在活动编辑页面新增"激励规则描述"模块，用于更直观地展示复杂的规则组合。
- 技术实现上，将在现有数据结构中新增字段以存储规则描述，并相应地进行数据库变更。
2. 积分活动排他性校验技术方案
- 为确保同一商品在特定时间段内只能匹配到一个活动，需建立一套排他性校验机制。
- 校验维度包括：活动时间范围、商品/品牌/生产日期范围、以及激励类型是否相同。
- 校验逻辑将应用于状态为"正式"且未开始或正在进行中的活动。
3. 盘点任务功能技术方案
- 设计了新的盘点任务管理功能，包含任务列表、创建、执行状态记录等。
- 数据库层面，将为盘点任务创建独立的主表和明细表。
4. 技术选型与架构规划
- 会议深入讨论了当前方案所依赖的"老活动"MySQL 数据库及其技术栈。
- 明确指出应遵循公司统一规划，将新业务（如门店积分）的数据存储迁移至新的技术数据底座（PG），以实现技术栈的收敛和长期维护。
- 当前方案中使用 MySQL 的决策被认为不符合长远规划，需进行调整。
待办
1. 技术方案调整与重新设计
- 盘点任务功能将不再使用 MySQL，需改为使用 PG 数据库，并重新设计相关技术方案。 — @粱健
- 在设计新表结构时，需确保主表和从表都包含创建时间、更新时间等标准的审计字段。 — @粱健
2. 技术方案对齐与汇报
- 李明非需与宋阳对齐，就如何将新功能接入 PG 技术底座达成一致，并向邱毅汇报。
- 李明非需与粱健、邱毅、宋洋等相关负责人，共同对齐并确定最终的技术方案。