sql 结果查询出来,但是一直处于运行状态

【 TiDB 使用环境】生产环境
【 TiDB 版本】v5.3.2
【遇到的问题】一个非常奇怪的现象,数据库这边运行一个sql,结果能够查出来,但是 session 一直处于query状态,kill tidb ID也不生效。也只有这个sql 是这样的情况。



通过cluster_processlist 查看,这个session的query time一直在增加,可实际上,结果已经返回:

我通过mysql 客户端执行该条sql,也是同样的,sql执行完毕,结果已经返回,但是session一直存在,即使关闭mysql客户端也同样一直存在,登陆到对应 tidb 节点去kill ,杀不掉,然后发现kill 在 v5.4以前有bug,目前唯一的解决办法是重启对应的 tidb-server。

sql:

select *
from (SELECT
      wde.weight_time,
      wde.review_end_time,
      wt.sign_ask,
      wdst.goodcount,
      wd.pack_no,
      wde.handover_time,
      CONCAT(
        IFNULL(service_province, ""),
        IFNULL(service_city, ""),
        IFNULL(service_district, ""),
        IFNULL(service_street, "")
      ) receive_address,
      wt.trans_ask
      FROM wd
               left JOIN wt
                         ON wd.do_id = wt.order_id
               left JOIN wde
                         ON wd.do_id = wde.do_id
               left JOIN wdst ON wd.do_id = wdst.orderid
      WHERE 1 = 1
        AND house_id = '3401001'
      AND partner_id = 'test'
      AND create_time >= '2022-09-01 00:00:00.0'
      AND create_time <= '2022-09-12 00:00:00.0'
      AND cust_id_list IN (
        '12345678',
        '22345678',
        '32345678',
        '42345678'
      )) t
order by create_time desc
limit 80000, 200;

目前改写sql为则恢复正常:

SELECT
  *
FROM
(
    SELECT
      wde.weight_time,
      wde.review_end_time,
      wt.sign_ask,
      wdst.goodcount,
      wd.pack_no,
      wde.handover_time,
      CONCAT(
        IFNULL(service_province, ""),
        IFNULL(service_city, ""),
        IFNULL(service_district, ""),
        IFNULL(service_street, "")
      ) receive_address,
      wt.trans_ask
    FROM
      (
      SELECT * FROM wd WHERE
      1 = 1
      AND house_id = '3401001'
      AND partner_id = 'test'
      AND create_time >= '2022-09-01 00:00:00.0'
      AND create_time <= '2022-09-12 00:00:00.0'
      AND cust_id_list IN (
        '12345678',
        '22345678',
        '32345678',
        '42345678'
      )
      ORDER BY
  create_time DESC
     LIMIT
 80000, 200
  ) wd

      LEFT JOIN wt ON wd.do_id = wt.order_id
      LEFT JOIN wde ON wd.do_id = wde.do_id
    LEFT JOIN wdst ON wd.do_id = wdst.orderid
  ) t

所以想知道造成这种现象的原因是什么?

附上Clinic诊断数据:

因为业务原因,该条sql的改写对源码的影响太大,目前不支持改写,所以各位有什么好的解决办法?或者知道造成这种现象的原因吗?

对集群设置了全局的 max_execution_time=3600000 也同样没效果。
image

cpu.profile (91.1 KB)
heap.profile (3.0 MB)
goroutine (12.9 KB)

goroutine打不开啊。

CONCAT( IFNULL(service_province, “”), IFNULL(service_city, “”), IFNULL(service_district, “”), IFNULL(service_street, “”) ) receive_address, 主要问题在这 你看一下你的行数 如果大于1000行 会占用tikv的cpu计算。一个节点的tikv是100%的

我觉着应该不是,你看我改写之后的sql,同样有这个查询,而且,我把这一个去掉了,还是一样,结果出来了,但是还是在一直运行。

你看看结果行有多少

这种意味着排序很耗时间的

一样的,你看改写后的sql,同样有limit 80000,200

200行不多呀。是不是代码里面没有commit

autocommit

我也遇到过,应该是bug,kill不掉的(查CLUSTER_PROCESSLIST也不行),占内存不释放,我的情况是其消耗大量的内存

我的也是这样,正打算 debug 看看能不能复现

有结果可以贴出来分享下,哈哈

相似问题的issue:https://github.com/pingcap/tidb/issues/35638