一句话总结

应收聚合改造已在预发完成结果一致和约 13 倍 SQL 加速验证，同时把慢查询增长拆解为流量放大与旧链路未全量切换，并修复 SAAS 优惠金额零值回退逻辑。

今日成果

  • 完成 DGJ2 receivableBalance() 提交 96d888caf7 的预发核验：部署文件一致、PHP lint/OPcache/健康检查通过；预发真实样本旧逻辑约 564.891ms、新 SQL 约 41.509ms，结果一致。
  • 完成 30/31 号 DAS CSV 对比：31 号业务 SQL 执行次数约增加 21.8%，加权平均耗时下降约 0.6%；主要增量来自销售单、收款、对账和客户应收页面调用，不是所有 SQL 单次变慢。
  • 完成多个慢 SQL 的线上只读 EXPLAIN 与结果核验：付款汇总去掉无用列后 746 行逐客户金额一致但仅约 1.51s → 1.48s；PDA 商品码候选单条码明显提速，但多条码字段取值不确定，未发布。
  • 提交 SAAS/GRS 优惠金额回退修复 75a68f874，并通过 46bcc4626 合入 staging；非零 activityAmount 优先，GRS 场景回退非零 disAmount。

问题与风险

  • getpAmount() 旧 SQL 仍是线上主要流量，新的聚合 SQL 尚未证明已全量切换；需补发布后 DAS、页面接口总耗时和并发 P95/P99。
  • receivableBalance() 的预发 SQL 回归通过，但尚未完成用户真实页面触发、重复调用次数与高并发长尾验证。
  • 付款/订单 COUNT 覆盖索引仍只完成候选设计；PDA 多条码优化不能在业务取值规则未明确时发布。
  • SAAS 优惠金额修复虽已合入 staging，但消费者重启后的真实订单回归、订单头与明细金额一致性仍待验证。

验证与证据

  • DGJ2 提交：96d888caf7；SAAS 提交：75a68f874、46bcc4626。
  • DGJ2 变更包：客户应收余额改为聚合查询。
  • 预发验证：目标文件 SHA-256 一致、PHP lint 通过、OPcache 文件变更检查开启、健康检查 HTTP 200、旧/新结果 MATCH。
  • 采集源：2026-09-01 源 JSON。

下一步

  • 补 getCustomerAccount 页面级接口与并发 P95/P99，确认线上是否仍执行旧 getpAmount()。
  • 在预发验证付款覆盖索引和订单 COUNT 覆盖索引；对真正单次退化 SQL 继续查执行计划。
  • 补 SAAS 优惠金额修复的消费者、优惠券/活动组合及明细金额回归。