没有不值得去解决的问题,也没有不值得去学习的技术!

在 MySQL 8.0 中,in 条件中的参数数量有 10000 个,导致查询时长过长,接口响应超时的分析

in 条件中的参数数量有 10000 个(产品需要上限是 10000 个),导致查询时长过长,接口响应超时

作者:

, ,

1、in 条件中的参数数量有 10000 个(产品需要上限是 10000 个),导致查询时长过长,接口响应超时。如图1

in 条件中的参数数量有 10000 个(产品需要上限是 10000 个),导致查询时长过长,接口响应超时


{
  "filter": {
    "plat_order_id": [
      1,
      2,
      3,
      4,
      5,
      6,
      7,
      8,
      9,
      10,
      ...,
      10000
    ]
  },
  "page": 1,
  "per_page": 100
}




{
    "status_code": 500,
    "code": 0,
    "message": "Maximum execution time of 300 seconds exceeded",
    "trace": {
        "line": 420,
        "file": "E:\\wwwroot\\erp-backend\\vendor\\laravel\\framework\\src\\Illuminate\\Database\\Connection.php",
        "class": "Symfony\\Component\\ErrorHandler\\Error\\FatalError",
        "trace": [
            "#0 {main}"
        ]
    }
}


2、当将 plat_order_id 的参数数量从 10000 个减少至 5 个后,接口响应不再超时,表中的记录总数为 2000 万条。如图2

当将 plat_order_id 的参数数量从  10000 个减少至 5 个后,接口响应不再超时,表中的记录总数为 2000 万条。

3、生成 SQL 如下



select
  count(*) as aggregate
from
  `orders`
where
  `orders`.`plat_order_id` in ('95798');


4、调整 SQL,决定强制使用索引 USE INDEX,不再超时



select
  count(*) as aggregate
from
  `orders` USE INDEX(`orders_plat_order_id_index`)
where
  `orders`.`plat_order_id` in ('95798')


需要长期技术维护或远程问题排查?

我是拥有 15+ 年经验的 PHP / Go 后端工程师,长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。

如果你的项目遇到以下情况,可以先从一次小问题排查开始合作:

  • ✅ PHP / Laravel / Yii2 老项目无人维护
  • ✅ Go / Gin 后端接口需要排查或优化
  • ✅ WordPress 网站访问慢、报错或插件冲突
  • ✅ Nginx / MySQL / Redis / Linux 服务器异常
  • ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
  • ✅ 需要长期远程技术支持或兼职维护

更多介绍请查看:关于我 & 合作

微信:13980074657
邮箱:shuijingwanwq@gmail.com
Telegram:@shuijingwan
GitHub:https://github.com/shuijingwan

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理