一句话总结

围绕 DAS 慢查询入口，完成价格变更日志、报价基础数据和 DGJ 生产日志量三条链路的只读定位与分层优化方案，均明确保持待实施边界。

今日成果

  • 定位 GuidPriceNotify::priceChange() → QuoteManagerSer::handlePriceChange() → QuotePriceChangeLogModel::getBatchUpdateList() 为价格变更日志入口；针对 841 次执行、平均 1.831 秒和约 91 万行扫描，提出联合索引、显式字段、ORDER BY id 和主键游标方案。
  • 拆分 updateBsGoodsInfo() 的同步比对、结算价巡检和报价规则页面三条链路；针对 64 张报价基础分表的 inv_id 访问放大和 (sid, inv_id) 索引不匹配，提出 inv_id 前导索引、源商品时间窗口索引及快照驱动方案。
  • 基于生产 Kibana 只读统计，确认 logstash-2026-09-05 约 1,846 万条日志/天；形成 BaseProvider 摘要化和 VIN 图片 Base64 关闭的 P0、按 Provider 保留业务摘要的 P1 治理顺序，保留 request_id/msg_id 关联。

问题与风险

  • 三项均为方案已明确待实施，未修改代码、索引、生产配置、采集策略或生产数据；日志降量约 25～45GB/日只是理论估算，必须同口径灰度验证。
  • 价格变更日志需要先确认联合索引现状、执行计划和状态更新失败语义；报价查询需分别验证 64 张分表结果集，不能简单增加 sid 或混用页面与后台任务方案。
  • 公共 Provider 完整请求/响应、大对象和 VIN Base64 是主要日志体积来源，但不能全局关闭日志或只缩短保留周期，否则会损失故障关联证据。

验证与证据

  • 生产 Kibana 仅做只读统计：约 1,846 万条/日，12:00～13:00 约 127 万条；前六类 Provider 约占样本字符量 91%。
  • 2026-09-06 私有复盘；原始来源：2026-09-06 JSON。
  • 原始采集：2 个会话、23 条消息、2 个唯一会话 ID；DGJ2 相关审计保持 L1，未将方案状态写成完成。

下一步

  • 在预发验证价格变更日志联合索引、显式投影、排序、游标推进和状态更新失败语义。
  • 对报价 64 张分表补真实执行计划、结果集对账、页面接口耗时和并发长尾数据。
  • 先对 BaseProvider 和 VIN 图片路径做单节点灰度，用同一 15 分钟窗口比较字符量、单条大小、耗时和错误率。