业务需求
需求描述

严重级别:严重
所属项目:java产品库(可能多平台那边的)
问题原因:慢SQL、大表JOIN,查询时间50秒左右,SQL为:(
SELECT p.id,p.sku,p.productGroupSku,qlength,qwidth,qheight,p.isGroup FROM ( SELECT rp.id, rp.sku AS sku, rp.product_group_sku AS productGroupSku,rp.is_group as isGroup, CASE WHEN rp.pack_length >0 AND rp.pack_width >0 AND rp.pack_height >0 THEN rp.pack_length ELSE rp.length END AS qlength, CASE WHEN rp.pack_length >0 AND rp.pack_width >0 AND rp.pack_height >0 THEN rp.pack_width ELSE rp.width END AS qwidth, CASE WHEN rp.pack_length >0 AND rp.pack_width >0 AND rp.pack_height >0 THEN rp.pack_height ELSE rp.height END AS qheight, CASE WHEN rp.pack_weight > 0 THEN rp.pack_weight ELSE rp.gross_weight END AS weight FROM rb_product_admin rpa INNER JOIN rb_product rp ON rpa.customer_id = rp.customer_id AND rpa.sku = rp.sku AND rp.delete_status=0 AND rpa.check_status = 1 WHERE rp.customer_id = 1 AND rp.id > 2215312 AND rpa.check_time >= '1995-07-10 12:50:21.019' AND rpa.check_time <= '2025-07-10 12:50:21.019' AND rp.product_state IN ( 0 , 1 ) AND rp.has_law_firm_agent IN ( -1 , 0 , 1 ) and rp.product_property in ( 2 ) and rp.is_group in ( 0 ) ) p ORDER BY id asc LIMIT 1000;
)
解决方案:(建议方案)当前查询,建议以rb_product表的ID为区间MQ事件{"min_id":1,"max_id":500},消费者单表回查rb_product,再通过rb_product_admin判断是否符合条件
验收标准
价值描述
降低风险 降低因为慢 SQL,导致的系统稳定性变差的问题,同时加快系统响应速度,提升用户体验 价值量估算:若不处理该慢 SQL,预估造成的影响 2W RMB/月
历史记录  
  1. 2025-07-14 08:15:34, 由 刘瀚泽 Bug转化而来,Bug编号为 58184 。
  2. 2025-07-16 14:55:34, 由 刘瀚泽 变更。
    修改了 版本号 ,旧值为 "1",新值为 "2"。
    修改了 需求名称,区别为:
    001- IMS:java产品库改造
    001+ IMS:多平台运营管理系统慢SQL及性能优化V8
    001- IMS:java产品库改造
    001+ IMS:多平台运营管理系统慢SQL及性能优化V8
    修改了 需求描述,区别为:
    001- 严重级别:严重 所属项目:java产品库(可能多平台那边的) 问题原因:慢SQL、大表JOIN,查询时间50秒左右,SQL为:( SELECT p.id,p.sku,p.productGroupSku,qlength,qwidth,qheight,p.isGroup FROM ( SELECT rp.id, rp.sku AS sku, rp.product_group_sku AS productGroupSku,rp.is_group as isGroup, CASE WHEN rp.pack_length &gt;0 AND rp.pack_width &gt;0 AND rp.pack_height &gt;0 THEN rp.pack_length ELSE rp.length END AS qlength, CASE WHEN rp.pack_length &gt;0 AND rp.pack_width &gt;0 AND rp.pack_height &gt;0 THEN rp.pack_width ELSE rp.width END AS qwidth, CASE WHEN rp.pack_length &gt;0 AND rp.pack_width &gt;0 AND rp.pack_height &gt;0 THEN rp.pack_height ELSE rp.height END AS qheight, CASE WHEN rp.pack_weight &gt; 0 THEN rp.pack_weight ELSE rp.gross_weight END AS weight FROM rb_product_admin rpa INNER JOIN rb_product rp ON rpa.customer_id = rp.customer_id AND rpa.sku = rp.sku AND rp.delete_status=0 AND rpa.check_status = 1 WHERE rp.customer_id = 1 AND rp.id &gt; 2215312 AND rpa.check_time &gt;= '1995-07-10 12:50:21.019' AND rpa.check_time &lt;= '2025-07-10 12:50:21.019' AND rp.product_state IN ( 0 , 1 ) AND rp.has_law_firm_agent IN ( -1 , 0 , 1 ) and rp.product_property in ( 2 ) and rp.is_group in ( 0 ) ) p ORDER BY id asc LIMIT 1000; ) 解决方案:(建议方案)当前查询,建议以rb_product表的ID为区间MQ事件{"min_id":1,"max_id":500},消费者单表回查rb_product,再通过rb_product_admin判断是否符合条件
    001+ 业务背景
    002+ (1)基于监控已发现有多个技术优化点,生产环境筛选时平均执行都是几十秒甚至几百秒,影响到系统和数据库的稳定,需要高优先解决,优化方案,架构师金荣已提供思路,可基于此完成代码优化
    003+ (2)针对开发主动提报的技术优化点,也统一收集并排期完成改造
    004+ <a href="https://alidocs.dingtalk.com/i/nodes/jb9Y4gmKWr7yNXM5har6eAlkVGXn6lpz?utm_scene=team_space" target="_blank" rel="noreferrer noopener">https://alidocs.dingtalk.com/i/nodes/jb9Y4gmKWr7yNXM5har6eAlkVGXn6lpz?utm_scene=team_space
    001- <br /> 严重级别:严重<br /> 所属项目:java产品库(可能多平台那边的)<br /> 问题原因:慢SQL、大表JOIN,查询时间50秒左右,SQL为:(<br /> SELECT p.id,p.sku,p.productGroupSku,qlength,qwidth,qheight,p.isGroup FROM ( SELECT rp.id, rp.sku AS sku, rp.product_group_sku AS productGroupSku,rp.is_group as isGroup, CASE WHEN rp.pack_length &gt;0 AND rp.pack_width &gt;0 AND rp.pack_height &gt;0 THEN rp.pack_length ELSE rp.length END AS qlength, CASE WHEN rp.pack_length &gt;0 AND rp.pack_width &gt;0 AND rp.pack_height &gt;0 THEN rp.pack_width ELSE rp.width END AS qwidth, CASE WHEN rp.pack_length &gt;0 AND rp.pack_width &gt;0 AND rp.pack_height &gt;0 THEN rp.pack_height ELSE rp.height END AS qheight, CASE WHEN rp.pack_weight &gt; 0 THEN rp.pack_weight ELSE rp.gross_weight END AS weight FROM rb_product_admin rpa INNER JOIN rb_product rp ON rpa.customer_id = rp.customer_id AND rpa.sku = rp.sku AND rp.delete_status=0 AND rpa.check_status = 1 WHERE rp.customer_id = 1 AND rp.id &gt; 2215312 AND rpa.check_time &gt;= '1995-07-10 12:50:21.019' AND rpa.check_time &lt;= '2025-07-10 12:50:21.019' AND rp.product_state IN ( 0 , 1 ) AND rp.has_law_firm_agent IN ( -1 , 0 , 1 ) and rp.product_property in ( 2 ) and rp.is_group in ( 0 ) ) p ORDER BY id asc LIMIT 1000;<br /> )<br /> 解决方案:(建议方案)当前查询,建议以rb_product表的ID为区间MQ事件{"min_id":1,"max_id":500},消费者单表回查rb_product,再通过rb_product_admin判断是否符合条件
    001+ <h4 style="font-size:12pt;margin-left:32px;">业务背景</h4>
    002+ <p>(1)基于监控已发现有多个技术优化点,生产环境筛选时平均执行都是几十秒甚至几百秒,影响到系统和数据库的稳定,需要高优先解决<span>,</span>优化方案,架构师金荣已提供思路,可基于此完成代码优化</p>
    003+ <p>(2)针对开发主动提报的技术优化点,也统一收集并排期完成改造</p>
    004+ <p><a href="https://alidocs.dingtalk.com/i/nodes/jb9Y4gmKWr7yNXM5har6eAlkVGXn6lpz?utm_scene=team_space" target="_blank" rel="noreferrer noopener">https://alidocs.dingtalk.com/i/nodes/jb9Y4gmKWr7yNXM5har6eAlkVGXn6lpz?utm_scene=team_space</a></p>
    修改了 验收标准,区别为:
    001-
    001+ 1、按照技术改造列表中的优化目标完成调整,当前反馈的问题得到解决
    001-
    001+ <p><span>1、按照技术改造列表中的优化目标完成调整,当前反馈的问题得到解决</span></p>
  3. 2025-07-16 14:56:37, 由 刘瀚泽 编辑。
    修改了 所属计划 ,旧值为 "",新值为 "2090"。
    修改了 每月价值量,旧值为 "16000",新值为 "20000"。
    修改了 预计工时 ,旧值为 "16",新值为 "32"。
    修改了 成本 ,旧值为 "8000",新值为 "16000"。
    修改了 ROI ,旧值为 "12.00",新值为 "7.50"。
    修改了 上线时间 ,旧值为 "2025-07-22",新值为 "2025-07-29"。
    修改了 所处阶段 ,旧值为 "wait",新值为 "planned"。
    修改了 价值描述 ,区别为:
    001- 待补充
    001+ 降低风险
    002+ 降低因为慢 SQL,导致的系统稳定性变差的问题,同时加快系统响应速度,提升用户体验
    003+ 价值量估算:若不处理该慢 SQL,预估造成的影响 2W RMB/月
    001- 待补充
    001+ 降低风险
    002+ 降低因为慢 SQL,导致的系统稳定性变差的问题,同时加快系统响应速度,提升用户体验
    003+ 价值量估算:若不处理该慢 SQL,预估造成的影响 2W RMB/月
  4. 2025-07-16 14:56:52, 由 刘瀚泽 指派给 任芳涛。
    修改了 指派给,旧值为 "",新值为 "renfangtao"。
  5. 2025-07-16 14:56:57, 由 刘瀚泽 记录评审结果,结果为 确认通过。
    修改了 评审时间,旧值为 "0000-00-00",新值为 "2025-07-16"。
    修改了 指派给 ,旧值为 "renfangtao",新值为 "liuhanze"。
    修改了 当前状态,旧值为 "draft",新值为 "active"。
    修改了 由谁评审,旧值为 "",新值为 "liuhanze"。
  6. 2025-07-16 20:11:37, 由 李乐同 关联到迭代 主干_7月V5版本_20250729 。
  7. 2025-07-16 20:42:04, 由 周杰 编辑。
    修改了 计划验收时间,旧值为 "0000-00-00",新值为 "2025-08-01"。
  8. 2025-07-23 20:19:43, 由 李乐同 编辑。
    修改了 预计工时,旧值为 "32",新值为 "51"。
    修改了 ROI ,旧值为 "7.50",新值为 "4.71"。
    修改了 成本 ,旧值为 "16000",新值为 "25500"。
  9. 2025-07-24 17:28:32, 由 李乐同 编辑。
    修改了 关键词,旧值为 "",新值为 "7/25提测"。
  10. 2025-07-29 08:59:31, 由 周杰 编辑。
    修改了 所处阶段 ,旧值为 "developed",新值为 "bepending"。
    修改了 设置阶段者,旧值为 "",新值为 "zhoujie"。
  11. 2025-07-30 10:07:05, 由 缪金荣 编辑。
    修改了 所处阶段,旧值为 "业务验收中",新值为 "业务验收通过"。
    功能验收:验收通过
    满意度:非常满意
    价值验收:完全达成
    原因备注:无
  12. 2025-08-02 09:39:36, 由 周杰 关闭,原因为 已完成 。
    修改了 由谁关闭,旧值为 "",新值为 "zhoujie"。
    修改了 关闭日期,旧值为 "0000-00-00 00:00:00",新值为 "2025-08-02 09:39:34"。
    修改了 指派给 ,旧值为 "renfangtao",新值为 "closed"。
    修改了 当前状态,旧值为 "active",新值为 "closed"。
    修改了 所处阶段,旧值为 "verified",新值为 "closed"。
    修改了 关闭原因,旧值为 "",新值为 "done"。
  13. 2025-09-12 10:03:56, 由 周杰 编辑。
    修改了 业务回填价值,旧值为 "0",新值为 "20000"。
    修改了 actualAchieveDesc ,旧值为 "",新值为 ""。
迭代版本
提报业务部门 技术研发中心
提报人员 万昌楠
需求来源 bug转需求
所属项目 技术中心-需求池
所属模块 多平台   java智能刊登
所属计划
业务价值
开发组 多平台开发组
受益业务部门 技术研发中心
验收人员 缪金荣
业务目标类型
中心业务目标
业务价值 提升人效
每月价值量 20000
每月节省人数 0
优先级 P1
价值类型 长期价值
预计工时 51
成本 250
ROI 80.00
操作手册 否
高价值 -
主被动 被动接收
复杂度 一般性
工作流ID
工作流创建时间 0000-00-00 00:00:00
更新点
是否高危 否
评分
当前状态 已关闭
所处阶段 已关闭
关键词 7/25提测
评审次数 一次
计划上线 2025-07-29
上线时间 2025-07-29
计划验收时间 2025-08-01
业务验收时间 2025-07-30 10:07:05
满意度 非常满意
价值验收 完全达成
满意度分值 100
业务回填价值 20000
验收达成价值 120000.0
验收达成ROI 4.71
抄送给 万昌楠  
由谁创建 刘瀚泽 于 2025-07-14 08:15:33
指派给 Closed 于 2025-08-02 09:39:34
由谁评审 刘瀚泽
评审时间 2025-07-16
由谁关闭 周杰 于 2025-08-02 09:39:34
关闭原因 已完成
最后修改 周杰 于 2025-08-02 09:39:34