1 min 数据查询 SQL 优化

本文针对一个查询离线设备状态的复杂SQL语句进行了优化。原SQL包含子查询和LIKE操作,执行效率低下。通过简化查询逻辑,使用带有索引的GROUP BY替代原有实现方式,大幅提升了查询速度,在百万级别数据量下,执行时间从1200ms缩短到仅80ms。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

问题

前几天线上数据库 IOPS 飙升,一直居高不下,最近并没有升级。遂查看数据库正在执行的 SQL 语句,发现有个查询离线设备的语句极其缓慢。

探寻原因

SELECT o.*
FROM
  (
    SELECT *
    FROM pim_online
    WHERE t2 IS NOT NULL
          AND username LIKE 'd.f.%'
          AND t2 + 32 * 60 * 1000 > +currentTimeMillis
          AND t2 + 32 * 60 * 1000 < currentTimeMillis
  ) o
WHERE o.username NOT IN (
  SELECT username
  FROM pim_online
  WHERE username LIKE 'd.f.%'
        AND t1 + 32 * 60 * 1000 > currentTimeMillis
)
GROUP BY o.username;

这段 SQL 执行特慢。以我的 SQL 知识分析,原因分析如下:

  1. 子查询很慢
  2. like 操作符很慢

优化

实现相同的功能,不一定要这么实现,可以用别的方式实现,用很简单的 group by 就能完成,group by 的字段还有索引。

SELECT
  DISTINCT
  username,
  max(t2) mt2
FROM pim_online
WHERE t2 IS NOT NULL
      AND left(username, 3) = 'd.f'
      AND t2 > 32 * 60 * 1000
      AND t2 < 30 * 60 * 1000
      AND t1 < 32 * 60 * 1000
GROUP BY username;

测试

用了 Java 生成 SQL 语句进行本地测试(排除网络延迟)。在数据量百万级别的时候,优化的 SQL 只需 80 ms 左右,原 SQL 需要 1200 ms,可谓惊人。

结论

  1. 子查询很慢
  2. like 操作符很慢
  3. 换种思路

转载于:https://www.cnblogs.com/Piers/p/9363550.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值