tidb sql 因为新建一个表,导致其他表的执行sql 无法返回结果

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:3.0 ga 版本

  • 【问题描述】:
    1.这个问题非常奇怪
    问题描述
    1.基于表A,一直跑着一个sql,使用kettle 执行,获取数据,昨天新建了表B,但是发现今天表A的sql,一直无法返回结果,使用kettle的tableinput,查看showprocesslit,sql一直存在,这个时候,从cpu和内存看,都执行完成了,很长时间之后,showprocesslist 的sql 消失,但是还是无结果。今天把昨天新建的表B,删除了,竟然A的sql 回复了。 想不明白。
    完全没有关系的2个表,咋会影响呢

  • 2.表A的sql:

SELECT billid,Max(StartTime) as StartTime,MIN(soc) AS rbsoc,MAX(soc) AS RESOC,
MAX(HighestTemperature) AS RHT,MIN(lowestTemperature) AS RLT,
MAX(HighestTemperature-lowestTemperature) AS RDiffT,
MAX(HighestVoltage) AS RSHV,MIN(LowestVoltage) AS RSLV,
MAX(HighestVoltage-LowestVoltage) AS RDifV,
IFNULL(
(
ROUND(max(CurrentElectricMeter))-ROUND(max(BillInitElectricMeter))
),0) AS RPower,

MAX(DemandVoltage) AS MaxDV, MIN(DemandVoltage) AS MinDV,MAX(DemandVoltageDemandCurrent) AS MaxDP,
MAX(DirectPower) AS MaxAP, SUM(DemandVoltage
DemandCurrent) AS DPower,SUM(DirectPower) AS APower,
MAX(DirectVoltageDirectCurrent) AS MaxPower,MAX(DirectVoltage) AS MaxRv,MAX(DirectCurrent) AS MaxRc,
MAX(DemandCurrent) AS MaxDC,ROUND(AVG(DemandVoltage
DemandCurrent),2) as AvgDP,ROUND(AVG(DirectPower),2) as AvgPower,
ROUND(sum(DemandVoltage),2) as SumDV,ROUND(sum(DemandCurrent),2) as SumDC,
ROUND(sum(DirectVoltage),2) as SumAV,ROUND(SUM(DirectCurrent),2) as SumAC
FROM ETL_SingleCharging
WHERE upttime>=DATE_FORMAT(DATE_ADD(current_date(),INTERVAL -2 DAY),‘%Y-%m-%d 00:00:00’)
AND upttime<DATE_FORMAT(current_date(),‘%Y-%m-%d 00:00:00’)
GROUP BY billid

  • 3.表B的数据结构

image

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出打印结果,请务必全选并复制粘贴上传。

麻烦确认下

  1. 问题描述的现象能否复现
  2. 表 A 的 sql 在 tidb_slow_query.log 中能否找到

可以复现。 2.A中在slow——query找不到 select query_time, query from information_schema.slow_query where is_internal = false – 排除 TiDB 内部的慢查询 SQL order by query_time desc limit 2;

貌似大数据量导入之后就出现

和sql 查询时间有关吗 查询3分多

日志出现异常 =“SELECT BILLID,MIN(HighestTemperature) AS MinMaxTemp,MAX(HighestTemperature) AS MaxMaxTemp\r\ FROM ETL_SingleCharging\r\ WHERE upttime>=DATE_FORMAT(DATE_ADD(current_date(),INTERVAL -2 DAY),’%Y-%m-%d 00:00:00’) \r\ AND upttime<DATE_FORMAT(current_date(),’%Y-%m-%d 00:00:00’) and Highes tTemperature<80 AND HighestTemperature>-40 and HighestTemperature<>0\r\ GROUP BY billid\r\ ”]

[err=“connection was bad\ngithub.com/pingcap/errors.AddStack\
t/home/jenkins/workspace/release_tidb_3.0/go/pkg/mod/github.com/pingcap/errors@v0.11.4/errors.go:174\ngithub.com/pingcap/errors.Trace\ \t/home/jenkins/workspa ce/release_tidb_3.0/go/pkg/mod/github.com/pingcap/errors@v0.11.4/juju_adaptor.go:15\ngithub.com/pingcap/tidb/server.(*packetIO).writePacket\ \t/home/jenkins/w orkspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/server/packetio.go:160\ngithub.com/pingcap/tidb/server.(*clientConn).writePacket\ \t/home/jenkins/wor kspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/server/conn.go:265\ngithub.com/pingcap/tidb/server.(*clientConn).writeChunks\ \t/home/jenkins/workspace /release_tidb_3.0/go/src/github.com/pingcap/tidb/server/conn.go:1314\ngithub.com/pingcap/tidb/server.(*clientConn).writeResultset\ \t/home/jenkins/workspace/r elease_tidb_3.0/go/src/github.com/pingcap/tidb/server/conn.go:1253\ngithub.com/pingcap/tidb/server.(*clientConn).handleQuery\ \t/home/jenkins/workspace/releas e_tidb_3.0/go/src/github.com/pingcap/tidb/server/conn.go:1170\ngithub.com/pingcap/tidb/server.(*clientConn).dispatch\ \t/home/jenkins/workspace/release_tidb_3 .0/go/src/github.com/pingcap/tidb/server/conn.go:885\ngithub.com/pingcap/tidb/server.(*clientConn).Run\ \t/home/jenkins/workspace/release_tidb_3.0/go/src/gith ub.com/pingcap/tidb/server/conn.go:644\ github.com/pingcap/tidb/server.(*Server).onConn\ \t/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/ tidb/server/server.go:438\ runtime.goexit\ \t/usr/local/go/src/runtime/asm_amd64.s:1337”]

  1. slow_query 表中记录的是这个 tidb server 当前 tidb_slow_query.log 中的内容,请确认下所有的 tidb server 的慢查询日志,包括历史日志,是否包含表 A 的 sql;ps: 我理解你说的 A的sql 回复了 表示该 sql 正常执行完成且返回结果。

  2. 如果所有 slow query 中找不到,说明该 sql 没有正常执行完成,而是异常中断了,从后面发的 dispatch error 报错也可以判断该 sql 并没有执行成功;

  3. 日志中 connection was bad 报错及 trace 信息表示 tidb server 正在 writePacket 回传数据,但是发现连接已经断开,可能的原因有

    • client 端主动断开连接,比如超时或人为触发或 client oom
    • 网络原因导致中断,比如网络抖动或丢包
    • 防火墙原因导致中断,比如防火墙的超时机制
    • server 端的网络参数如 somaxconn 设置不合理
  4. 从前面的描述,如果现象可以复现且日志中对应时间可以找到上面的报错,可能是 kettle client 端的行为导致连接断开,建议在 tidb server 本机通过 mysql 客户端连接并执行 sql,看能否正常执行完成。