OceanBase 4.0 解读：全链路追踪要解决什么问题？从一条慢SQL说起
作者简介： 肖意，OceanBase高级技术专家。 曾多次参加蚂蚁双十一大促支持工作，是TPC-C、TPC-H性能攻坚项目组核心成员，主要负责SQL引擎相关研发，包括链路协议、执行计划管理、执行引擎等方向的设计与开发工作。
在上一篇 4.0 解读文章中，我们回顾了单机到分布式跨越给数据库 DDL 带来的挑战，并介绍了 OceanBase 的应对策略及设计思路，以便为用户提供更高效、更透明的运维体验。 本篇将继续数据库运维的话题，展开对故障追踪与定位能力的讨论。
首先让我们看下这样一个场景:
业务部门：数据库请求好慢，可以看看哪里出问题了吗？
DBA： 【DBA 查看数据库节点实时监控】我在数据库节点的实时监控并未发现很慢的 SQL。
业务部门：那是怎么回事？
DBA：可能是客户端到数据库节点这一链路有问题，我来看一下中间代理服务器的日志。
DBA：【 DBA 开始查询日志，1 hour later……】从代理服务器日志看耗时也是正常的。可能是客户端到代理服务器的网络问题？
该场景描述的是分布式数据库下运维遇到慢 SQL 时的场景，如果运维无法及时找出问题原因，就会非常影响使用体验，甚至导致业务服务不可用。因此，如何提供简单、高效的诊断能力，一直是我们思考的问题。相比单机数据库，分布式数据库系统涉及多个节点、多组件协同工作，集群规模可能达到几十、上百台服务器，用户请求链路会更加复杂，要实现快速高效地问题诊断与定位也会更有挑战。
OceanBase 4.0 在诊断能力方面有了显著提升，其中包括首次实现对 SQL 请求的可视化全链路追踪，能够帮助用户快速追踪并定位具体问题发生在哪个执行阶段、哪台机器以及哪个模块，并提供具体的相关执行信息，为用户提供简单、高效的运维体验。 本文将分享我们对数据库高效诊断的思考，介绍 OceanBase全链路追踪能力及设计思路。
- 全链路追踪要解决什么问题；
- 全链路追踪的关键能力有哪些；
- 我们如何设计全链路追踪；
- 4.0 全链路追踪效果展示。
