创建绑定执行计划报错:ERROR 1105 (HY000): runtime error: invalid memory address or nil pointer dereference

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
v4.0.13

【概述】 场景 + 问题概述
创建绑定执行计划报错:
ERROR 1105 (HY000): runtime error: invalid memory address or nil pointer dereference


【背景】 做过哪些操作
create global binding for select * from t2 where a = 8 and b=‘s’ using select * from t2 where a = ? and b=‘s’;
【现象】 业务和数据库现象
报错:ERROR 1105 (HY000): runtime error: invalid memory address or nil pointer dereference
【问题】 当前遇到的问题

执行计划经常变化,不准确,导致生产环境极性能很不稳定
业务修改代码sql代价太高,需要手动绑定执行计划

【业务影响】
tidb性能不稳定

【TiDB 版本】
v4.0.13

【应用软件及版本】

【附件】 相关日志及配置信息

  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息

监控(https://metricstool.pingcap.com/)

  • TiDB-Overview Grafana监控
  • TiDB Grafana 监控
  • TiKV Grafana 监控
  • PD Grafana 监控
  • 对应模块日志(包含问题前后 1 小时日志)

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

1赞

a=? 这种写法感觉不对吧,你参考下官网的示例:
https://docs.pingcap.com/zh/tidb/stable/sql-statement-create-binding

你是想在binding里面用到a,b的索引吗

现在的问题是,用什么索引没关系,binding直接就报错了

你在binding后面那个select * 加上 use index(idx_t2_a)试试,怀疑和语法有关,要不然可能就是bug了

试过了,兄弟,use_index,force index,都会报错的

能否把报错的 tidb 的 log 上传一下

[2021/12/03 11:18:48.808 +08:00] [ERROR] [conn.go:727] [“connection running loop panic”] [conn=362837] [lastSQL=“create global binding for select * from t2 where a = 8 and b=‘s’ using select * from t2 where a = 3 and b=‘s’”] [err=“runtime error: invalid memory address or nil pointer dereference”] [stack=“goroutine 56878269 [running]:\ngithub.com/pingcap/tidb/server.(*clientConn).Run.func1(0x38d3be0, 0xc00cdedf50, 0xc004462100)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/conn.go:725 +0xee\npanic(0x2fb0d20, 0x4f3ffc0)\n\t/usr/local/go/src/runtime/panic.go:679 +0x1b2\ngithub.com/pingcap/tidb/executor.getDbFromResultNode(0x38d5ba0, 0xc00cca5c30, 0xc00d0644c0, 0x1, 0x203002)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/executor/compiler.go:275 +0x480\ngithub.com/pingcap/tidb/executor.getDbFromResultNode(0x38d5ce0, 0xc010de6000, 0xc0120ca300, 0xc0004d6000, 0x7f4d46b70d98)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/executor/compiler.go:269 +0x158\ngithub.com/pingcap/tidb/executor.getDbFromResultNode(0x38d50a0, 0xc0114aaf00, 0xa018c063d3b6eb0f, 0xc00d0644c0, 0x1)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/executor/compiler.go:278 +0x390\ngithub.com/pingcap/tidb/executor.getStmtDbLabel(0x38dc620, 0xc010de6080, 0x1)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/executor/compiler.go:233 +0x5c3\ngithub.com/pingcap/tidb/executor.CountStmtNode(0x38dc620, 0xc010de6080, 0x391b100)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/executor/compiler.go:162 +0x18f\ngithub.com/pingcap/tidb/executor.(*Compiler).Compile(0xc00491ce78, 0x38d3be0, 0xc00affe2d0, 0x38dc620, 0xc010de6080, 0x0, 0x0, 0x0)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/executor/compiler.go:67 +0x32f\ngithub.com/pingcap/tidb/session.(*session).ExecuteStmt(0xc00ab79180, 0x38d3be0, 0xc00affe2d0, 0x38dc620, 0xc010de6080, 0x0, 0x0, 0x0, 0x0)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/session/session.go:1359 +0x286\ngithub.com/pingcap/tidb/server.(*TiDBContext).ExecuteStmt(0xc0077bc450, 0x38d3be0, 0xc00affe2d0, 0x38dc620, 0xc010de6080, 0x7f4d46b70d98, 0x0, 0xc005214ed0, 0x11c0083)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/driver_tidb.go:269 +0x65\ngithub.com/pingcap/tidb/server.(*clientConn).handleStmt(0xc004462100, 0x38d3be0, 0xc00affe2d0, 0x38dc620, 0xc010de6080, 0xc011910001, 0x0, 0x0)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/conn.go:1449 +0x8e\ngithub.com/pingcap/tidb/server.(*clientConn).handleQuery(0xc004462100, 0x38d3be0, 0xc00affe2d0, 0xc0041a11f1, 0x6d, 0x0, 0x0)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/conn.go:1438 +0x225\ngithub.com/pingcap/tidb/server.(*clientConn).dispatch(0xc004462100, 0x38d3b20, 0xc013135fc0, 0xc0041a11f1, 0x6e, 0x6d, 0x0, 0x0)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/conn.go:1016 +0x723\ngithub.com/pingcap/tidb/server.(*clientConn).Run(0xc004462100, 0x38d3be0, 0xc00cdedf50)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/conn.go:785 +0x293\ngithub.com/pingcap/tidb/server.(*Server).onConn(0xc002233ce0, 0xc004462100)\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/server.go:452 +0xb0d\ncreated by github.com/pingcap/tidb/server.(*Server).Run\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/server.go:355 +0x7c9\n”]

这个是个已经定位的 bug
https://github.com/pingcap/tidb/issues/29503
目前 master 分支和 5.3 上的最新版本已经修复,其它分支预计会在下个版本修复。
触发这个 bug 的必要条件是 record-db-qps 被打开。
作为临时的绕过措施,可以在某一台 tidb 上关掉 record-db-qps 创建 binding。

1赞

关于执行计划不稳定的问题,能提供更多信息吗,比如 SQL、选错的计划、预期的计划、统计信息?
统计信息和计划选择方面在最近几个版本有不少优化,可能已经可以解决问题。

好的,谢谢

现象就是,比如一个表,a字段和b字段都有索引,sql查询where条件里,两个字段都有过滤,明显走a索引会更快,但是经常会变成走b字段的索引,重新analyze之后,就好了,这个等问题再出现,我继续跟帖发截图

好的。

因为有敏感信息,所以私信发您了,另外,这个表经常会有较大批量写入,但是一直同样的索引才是最合理的,现在情况是,批量变化之后一段时间,执行计划变成走了错误的索引