重现步骤

[步骤]

1 进入Allegro-LISTING管理,状态选择已上架,其他全部不设置条件,点击搜索

https://imp.zhcxkj.com/marketplace/Allegrolisting/searchcount

{"input":{"PageSize":20,"SearchType":"3","SearchValue":"","Status":["1"],"BatchSearchType":"4","SearchProductType":"1"},"current":1,"pageSize":20,"language":"zh_cn"}

响应:

[结果]


[期望]


历史记录  
  1. 2022-08-09 14:16:15, 由 闫峰 创建。
  2. 2022-08-09 18:15:24, 由 刘瀚泽 指派给 闫峰。
    修改了 指派给,旧值为 "weisicheng",新值为 "yanfeng"。
  3. 2022-08-10 16:14:45, 由 shilin 解决,方案为 非BUG-纯属误判 。
    修改了 解决方案,旧值为 "",新值为 "feiBUG"。
    修改了 解决日期,旧值为 "",新值为 "2022-08-10 16:13:35"。
    修改了 Bug状态 ,旧值为 "active",新值为 "resolved"。
    修改了 是否确认,旧值为 "0",新值为 "1"。
    修改了 解决者 ,旧值为 "",新值为 "shilin"。

    504 你查询的时间可能服务器正在忙。

  4. 2022-08-11 10:00:43, 由 闫峰 编辑。
    修改了 影响环境,旧值为 "590,",新值为 "590"。

    这个bug在规定的场景下必现,查找条件是

    {

    "input": {
    "PageSize": 20,
    "SearchType": "4",
    "Status": ["1"],
    "BatchSearchType": "4",
    "SearchProductType": "1"
    },
    "current": 1,
    "pageSize": 20,
    "language": "zh_cn"
    }
  5. 2022-08-11 10:01:35, 由 闫峰 指派给 shilin。
    修改了 指派给,旧值为 "yanfeng",新值为 "shilin"。
  6. 2022-08-11 11:18:00, 由 shilin 激活。
    修改了 Bug状态 ,旧值为 "resolved",新值为 "active"。
    修改了 激活日期,旧值为 "",新值为 "2022-08-11 11:18:00"。
    修改了 激活次数,旧值为 "0",新值为 "1"。
    修改了 解决方案,旧值为 "feiBUG",新值为 ""。
    修改了 解决日期,旧值为 "2022-08-10 16:13:35",新值为 "0000-00-00"。
    修改了 解决者 ,旧值为 "shilin",新值为 ""。
    修改了 关闭日期,旧值为 "",新值为 "0000-00-00"。
  7. 2022-08-11 11:55:22, 由 shilin 解决,方案为 服务器原因 。
    修改了 解决方案,旧值为 "",新值为 "server"。
    修改了 解决日期,旧值为 "",新值为 "2022-08-11 11:18:07"。
    修改了 指派给 ,旧值为 "shilin",新值为 "yanfeng"。
    修改了 Bug状态 ,旧值为 "active",新值为 "resolved"。
    修改了 解决者 ,旧值为 "",新值为 "shilin"。

    我来给你解释下:


    执行查询总数后,生成的 SQL 为:


    SELECT COUNT(*) FROM `M_Allegro_Listing` WHERE `CustomerId` = 1 AND NOT (`Sku` = '' OR `Sku` IS NULL) AND `OnlineStatus` IN (1)

    该语句需要整整 7.5 分钟才能执行出结果。


    分析:

    1 CurstomerId 是必填参数,即使做了索引,他也是全部数据。

    2 SKU 可以为空,这就导致,在 SKU 做的索引,有可能失效。

    3 OnlineStatus 类型存在 5 种,也就是说分了 5 块。


    这里重大的 BUG 是,把为空的 SKU 设置为索引,可以导致索引失效。


    优化


    现在按最优先分 5 块数据区,然后再查询,我们看看查询耗时是多少


    需要 11 秒


    那么带上 可空的 SKU 呢?

    然后带上必填参数 CustomerId 呢?


    需要 2 分钟 13 秒。

    小于实际执行的  7.5 分钟。

    是否还能优化?

    能!

    移除 CustomerID 这个实际没必要的 冗余参数。

    仅需 5 秒。

    是否还能继续优化?

    能!

    请申请专业的查询引擎工具,而非直接 DQL。当业务自定义查询条件时,DBA 并不能保证每一种搜索条件组合都能命中索引。这时,专业的搜索引擎就显露出他的效率了。



  8. 2022-08-18 16:18:54, 由 闫峰 指派给 刘瀚泽。
    修改了 指派给,旧值为 "yanfeng",新值为 "liuhanze"。

    请产品确认此接口是否需要优化

    目前此接口在这种场景下100%报504错误

  9. 2022-08-22 14:12:59, 由 闫峰 编辑。
    修改了 所属计划,旧值为 "0",新值为 "618"。
  10. 2022-08-22 18:45:54, 由 刘瀚泽 指派给 胡笑锋。
    修改了 指派给,旧值为 "liuhanze",新值为 "huxiaofeng"。
  11. 2022-09-12 17:22:59, 由 胡笑锋 关闭。
    修改了 Bug状态 ,旧值为 "resolved",新值为 "closed"。
    修改了 指派给 ,旧值为 "huxiaofeng",新值为 "closed"。
    修改了 由谁关闭,旧值为 "",新值为 "huxiaofeng"。
    修改了 关闭日期,旧值为 "",新值为 "2022-09-12 17:22:59"。
    华为云优化后暂无发现
  12. 2023-11-17 09:48:36, 由 刘超 编辑。
    修改了 所属模块,旧值为 "1659",新值为 "1871"。
所属项目 技术中心-需求池
所属模块 多平台   allegro
所属计划 智能刊登系统优化专项
所属迭代
Bug类型
严重程度 提示
优先级 P2
Bug状态 已关闭
业务部门
影响功能
开发责任人
测试责任人
解决时效 0
激活次数 1
激活日期 2022-08-11 11:18:00
是否确认 是
当前指派 Closed 于 2022-09-12 17:22:59
截止日期 0000-00-00
上线时间
上线时效
操作系统
浏览器
关键词
抄送给
所属迭代
相关需求
相关任务
由谁创建 闫峰 于 2022-08-09 14:16:15
影响环境 590
由谁解决 shilin 于 2022-08-11 11:18:07
解决版本
解决方案 服务器原因
由谁关闭 胡笑锋 于 2022-09-12 17:22:59
最后修改 刘超 于 2023-11-17 09:48:33
相关Bug