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

[magongyong]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 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 小时日志）

---

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

[hey-hoho]

@magongyong

create global binding for select * from t2 where a = 8 and b=‘s’ using select * from t2 where a = ? and b=‘s’;

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

[magongyong]

[hey-hoho]

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

[magongyong]

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

[hey-hoho]

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

[magongyong]

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

[wink (winkyao)]

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

[magongyong]

[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)\ \t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/conn.go:725 +0xee\ panic(0x2fb0d20, 0x4f3ffc0)\ \t/usr/local/go/src/runtime/panic.go:679 +0x1b2\ngithub.com/pingcap/tidb/executor.getDbFromResultNode(0x38d5ba0, 0xc00cca5c30, 0xc00d0644c0, 0x1, 0x203002)\ \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)\ \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)\ \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)\ \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)\ \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)\ \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)\ \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)\ \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)\ \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)\ \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)\ \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)\ \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)\ \t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/server.go:452 +0xb0d\ created by github.com/pingcap/tidb/server.(*Server).Run\ \t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/server.go:355 +0x7c9\ ”]

[magongyong]

[time-and-fate]

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

[time-and-fate]

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

[magongyong]

好的，谢谢

[magongyong]

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

[time-and-fate]

好的。

[magongyong]

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