根据你提供的这个堆栈，我翻了下代码。感觉非常迷惑。
以我粗浅的经验来说，这个堆栈最上面的地方就是空指针引用到的对象。
https://github.com/pingcap/tidb/blob/v7.1.1/store/copr/coprocessor.go#L1098
这个1098行的报错，让我觉得这个worker对象因为某种原因为null。感觉这个结论非常不靠谱。 
菜了菜了。
select * from INFORMATION_SCHEMA.CLUSTER_STATEMENTS_SUMMARY_HISTORY limit 1;
这个sql如果查询固定报错的话，建议直接去github上提个bug。
不过内容除了报错的堆栈以外，建议也提供一下执行sql的现场信息，更好排查。
https://docs.pingcap.com/zh/tidb/stable/sql-plan-replayer#plan-replayer-导出示例
PLAN REPLAYER DUMP EXPLAIN select * from INFORMATION_SCHEMA.CLUSTER_STATEMENTS_SUMMARY_HISTORY limit 1;
执行上述语句，然后去每个tidb上去找一下返回的zip文件的名称。把这个zip文件也上传到issue里面去。这样更方面pingcap的开发排查问题。
zip里面不会包含用户数据的。你不放心可以打开自己看的。