重现步骤

[步骤]


(@p1 bigint)select t.ID,t.CustomerID,t.WareHouseID,t.TransportName,w.WareHouseType,w.WareHouseName,t.WareHouseIDs from  RB_Transport t with(nolock) INNER JOIN RB_WareHouse w with(nolock) on t.WareHouseID = w.ID and t.CustomerID = w.CustomerID where t.CustomerID =@p1 and t.IsActive = 1 order by SortBy DESC;

[结果]


[期望]

建议使用缓存


历史记录  
  1. 2024-07-10 18:15:19, 由 袁慧斌 创建。
  2. 2024-07-10 18:16:17, 由 李乐同 指派给 程伟。
    修改了 指派给，旧值为 "liletong"，新值为 "chengwei"。
  3. 2024-07-10 19:10:17, 由 程伟 指派给 李振宇。
    修改了 指派给，旧值为 "chengwei"，新值为 "lizhenyu"。
    看下是不是价格计算器子系统接口的SQL
  4. 2024-07-10 21:51:20, 由 李振宇 编辑。
    修改了 解决时效，旧值为 "0"，新值为 "-1"。

    备注：没有找到对应的sql

  5. 2024-07-10 21:51:26, 由 李振宇 指派给 程伟。
    修改了 指派给，旧值为 "lizhenyu"，新值为 "chengwei"。
  6. 2024-07-10 21:56:02, 由 程伟 指派给 李乐同。
    修改了 指派给，旧值为 "chengwei"，新值为 "liletong"。
    不是我们这边的
  7. 2024-07-11 00:29:15, 由 李乐同 指派给 袁慧斌。
    修改了 指派给，旧值为 "liletong"，新值为 "yuanhuibin"。
    确认下谁创建的SQL
  8. 2024-07-11 14:48:00, 由 袁慧斌 指派给 李乐同。
    修改了 指派给，旧值为 "yuanhuibin"，新值为 "liletong"。
    看看战略部门的谁处理一下
  9. 2024-07-11 16:10:40, 由 李乐同 指派给 鞠智明。
    修改了 指派给，旧值为 "liletong"，新值为 "juzhiming"。
  10. 2024-07-11 16:31:31, 由 鞠智明 指派给 李乐同。
    修改了 指派给，旧值为 "juzhiming"，新值为 "liletong"。
    看上面振宇的回复 ，不是我们这边的 
  11. 2024-07-11 16:33:30, 由 程伟 指派给 宋宇。
    修改了 指派给，旧值为 "liletong"，新值为 "songyu"。
    go接口，帮忙找下接口名称
  12. 2024-07-11 16:45:01, 由 宋宇 指派给 程伟。
    修改了 指派给，旧值为 "songyu"，新值为 "chengwei"。
    /erp/system/transports
    /erp/system/alltransports
  13. 2024-07-11 17:31:12, 由 程伟 编辑。
    修改了 解决时效，旧值为 "0"，新值为 "23.26"。
    修改了 上线时效，旧值为 "-1"，新值为 "17747394.26"。
    我这边已确认不是我这边的
  14. 2024-07-11 17:32:06, 由 程伟 指派给 何建宝。
    修改了 指派给，旧值为 "chengwei"，新值为 "hejianbao"。
    宝哥你确认下，如果不是你的，就转给下一个还没确认的同事，大家都确认下
  15. 2024-07-11 18:14:07, 由 何建宝 指派给 程伟。
    修改了 指派给，旧值为 "hejianbao"，新值为 "chengwei"。

    看提交记录是之前架构添加的，鹏明这边改过一版，表是你这边的，直接处理下吧

  16. 2024-07-11 18:18:03, 由 程伟 指派给 许瑞丰。
    修改了 指派给，旧值为 "chengwei"，新值为 "xuruifeng"。
    宝哥已经确认不是他的了，你再确认下
  17. 2024-07-15 15:48:46, 由 许瑞丰 指派给 程伟。
    修改了 指派给，旧值为 "xuruifeng"，新值为 "chengwei"。

    建议不要继续传了，信息也比较明确了，

    从上面GIT日志，其他小组没有变更多

    从表名属于订单组模块

  18. 2024-07-15 16:03:29, 由 程伟 指派给 许瑞丰。
    修改了 指派给，旧值为 "chengwei"，新值为 "xuruifeng"。

    订单组很多表都是基础表，几乎整个研发中心都有使用到。

    如果每个组对于订单组的基础公共表都自己写一个查询接口，出了问题，就往订单组这边堆的话，订单组就一直改不完了。


    换句话说，客户订单页面也有关联利润表查询，如果查询超时了，是不是该利润组来优化。


    我建议，找到谁在大量调用这个接口的同事，由他来修改

  19. 2024-07-15 16:13:17, 由 程伟 指派给 黄金龙。
    修改了 指派给，旧值为 "xuruifeng"，新值为 "huangjinlong"。
  20. 2024-07-31 19:56:54, 由 官荣荣 编辑。
    修改了 开发责任人，旧值为 ""，新值为 "huangjinlong"。
    修改了 解决时效 ，旧值为 "23.26"，新值为 "505.69"。
    修改了 上线时效 ，旧值为 "17747400"，新值为 "17747394.26"。
  21. 2024-09-02 10:16:21, 由 李乐同 指派给 袁慧斌。
    修改了 指派给，旧值为 "huangjinlong"，新值为 "yuanhuibin"。
  22. 2024-09-04 10:31:04, 由 袁慧斌 解决，方案为 系统设计缺陷 。
    修改了 解决方案，旧值为 ""，新值为 "bydesign"。
    修改了 解决版本，旧值为 ""，新值为 "577"。
    修改了 解决日期，旧值为 ""，新值为 "2024-09-04 10:30:30"。
    修改了 Bug状态 ，旧值为 "active"，新值为 "resolved"。
    修改了 是否确认，旧值为 "0"，新值为 "1"。
    修改了 解决者 ，旧值为 ""，新值为 "yuanhuibin"。
  23. 2024-09-04 10:31:07, 由 袁慧斌 关闭。
    修改了 Bug状态 ，旧值为 "resolved"，新值为 "closed"。
    修改了 指派给 ，旧值为 "yuanhuibin"，新值为 "closed"。
    修改了 由谁关闭，旧值为 ""，新值为 "yuanhuibin"。
    修改了 关闭日期，旧值为 ""，新值为 "2024-09-04 10:31:07"。
所属项目 技术中心-需求池
所属模块 供应链   仓储物流
所属计划
所属迭代
Bug类型
严重程度 一般
优先级 P0
Bug状态 已关闭
业务部门
影响功能
开发责任人 黄金龙
测试责任人
解决时效 505.69
激活次数 0
激活日期
是否确认 是
当前指派 Closed 于 2024-09-04 10:31:07
截止日期 0000-00-00
上线时间 0000-00-00 00:00:00
上线时效 17747400
操作系统
浏览器
关键词
抄送给
所属迭代
相关需求
相关任务
由谁创建 袁慧斌 于 2024-07-10 18:15:19
影响环境 577
由谁解决 袁慧斌 于 2024-09-04 10:30:30
解决版本 ERP-生产环境
解决方案 系统设计缺陷
由谁关闭 袁慧斌 于 2024-09-04 10:31:07
最后修改 袁慧斌 于 2024-09-04 10:31:07
相关Bug