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(DemandVoltageDemandCurrent) AS DPower,SUM(DirectPower) AS APower, MAX(DirectVoltageDirectCurrent) AS MaxPower,MAX(DirectVoltage) AS MaxRv,MAX(DirectCurrent) AS MaxRc, MAX(DemandCurrent) AS MaxDC,ROUND(AVG(DemandVoltageDemandCurrent),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\n FROM ETL_SingleCharging\r\n WHERE upttime>=DATE_FORMAT(DATE_ADD(current_date(),INTERVAL -2 DAY),’%Y-%m-%d 00:00:00’) \r\n AND upttime<DATE_FORMAT(current_date(),’%Y-%m-%d 00:00:00’) and Highes tTemperature<80 AND HighestTemperature>-40 and HighestTemperature<>0\r\n GROUP BY billid\r\n”]

[err=“connection was bad\ngithub.com/pingcap/errors.AddStack\n
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\n\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\n\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\n\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\n\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\n\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\n\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\n\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\n\t/home/jenkins/workspace/release_tidb_3.0/go/src/gith ub.com/pingcap/tidb/server/conn.go:644\ngithub.com/pingcap/tidb/server.(*Server).onConn\n\t/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/ tidb/server/server.go:438\nruntime.goexit\n\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,看能否正常执行完成。