细化报错信息，方便运维排错。

需求反馈
请清晰准确地描述问题场景、需求行为及背景信息，更有利于产品同学及时跟进需求
【需求涉及的问题场景】
TiDB 在运行过程中，可能会报这样、那样的错误。而错误信息仅仅是一段笼统的描述文字。可能官方开发人员根据报错信息，一眼就能定位主要的问题原因。但是，使用者看着笼统的错误信息，就很蒙逼，无从下手。
比如，这几天做生产环境的BR恢复测试时，就遇到报错 other error: Coprocessor task terminated due to exceeding the deadline。看着一脸蒙，这个other error 是个什么错误？是不是类似于 Python 中异常的基类（Exception），所有错误都可以归类为 other error？这个 deadline（最后期限）又是个啥？印象里，官方的 TiKV 视频教程中，也没提过这个 deadline 啊？和磁盘的调度队列 deadline、my-deadline 是否有关系？翻官方 github，找到关于 Coprocessor task terminated due to exceeding the deadline 的定义。

2c711860b8ae3d019c07b8c8d5abc041642×897 84.2 KB

【期望的需求行为】
参考 Oracle 的 ORA-XXX 错误号的思路，详细定义每个错误号、原因、及可能的解决方案。比如：看到 ORA-00600 就知道是内部错误，可能是遇到了 bug,或者根据后续几位的参数，翻阅 support 可以解决大部分的问题。

image1013×543 54.1 KB

【背景信息】
报错更明确，用户可根据提示，自助解决大部分的常见问题。

建议不错。

建议不错，报错信息确实很多看不懂

确实应该加错误id

参考oracle出一个报错列表自己去查找挺好

点赞

报错细化需要代码优化，这个建议是很好的，还有等待事件的细化，wait event

现在的 TiDB 似乎是一匹脱了疆的野马，各种新特性都很吸引人。但是，细细品味每个特性都做不到完美，需要更多地去优化。久而久之，越攒越多，越欠越多。
个人感觉，应该将一部分能切中用户痛点的特性，做细、做完美，而不是做一款大而全的产品。

说到这个，我就不得不提，昨天无意中看到的pingcap cto的一篇文章。

在这里再贴一次，里面有很多来自cto对自家产品的吐槽。很有意思。

这个确实可以优化成错误解释码

大佬的建议很中肯，附议

希望官方能够倾斜过来更多资源到这一方面的优化

深度好文啊！文中关于监控的描述，之前我在帖子里也提到过。TiDB Grafana 有很多监控（至少得上百个吧），数据库出问题的时候就一脸蒙蔽，图表太多无从下手。还有集群的配置调整，有pd的、有tidb的、有tikv的，有动态可调的，有需要改配置文件重新加载的。也是一脸懵B，参数太多了。记不住，根本记不住。

就敬佩 tidb 这个范：敢于对外批评自己，从不中伤友商

我记得我前几天提问了个参数问题，就很懵逼，好几天才弄明白，到现在又记不清楚了。参数持久化到etcd中，哪个配置文件都看不到

爱之深，责之切