MySQL数据库性能诊断产品DBdoctor介绍

背景

2020年从阿里云离职回到了美丽的家乡大青岛，庆幸的是还可以继续从事数据库相关研发工作，入职海信集团旗下的聚好看科技股份有限公司，一开始我也以为海信只做家电，实际上现在的家电都是互联网家电了，以电视为例，海信电视有全球上亿的用户，晚高峰，春晚都是流量洪峰，电视从开机开始，有账号、会员、广告、媒资、电商、推荐、搜索，千人千面，是真正的互联网体系，所以会有大量的数据需要保存分析，因此这里有大规模的数据库应用场景，公司有数据库运维、数据库管控、数据库内核团队，来支撑整个家电用户的稳定性，所以这三年我依然在做数据库管控，主要负责数据库工具的产品化，到目前为止我们孵化出了数据库私有云管理平台(基于K8S的数据库云管)，数据库性能诊断产品(聚焦于数据库性能)，数据库安全产品(聚焦于数据库操作安全SQL管理)。扯得有点多，今天主要跟大家分享我们的性能诊断产品DBdoctor，后续会进行连载。

DBdoctor介绍

DBdoctor我们内部称为数据库性能诊断专家，可以对数据库做细粒度的扫描，帮助您五分钟内找到数据库性能问题，实现性能诊断百倍提效，针对数据库性诊断门槛高、耗时长的问题，DBdoctor 提供了快速易用的解决方案，基于海量数据实时分析技术，深入到数据库内核，提供
精准的诊断分析和优化建议。
以往我们定位数据库性能问题会先看资源监控，发现资源抖动后会去查看实例监控，比如QPS、RT、会话数、线程数、读写情况等，再去看慢SQL，或者查看锁等，在分析慢SQL时如果正好出问题的时刻发现一条或者一类执行耗时较久的SQL，非常庆幸，基本要定位到问题了，但是往往的现象是资源打满情况下会漫天遍野的慢SQL，之前不慢的也成了慢SQL，这时候就比较头疼。DBdoctor则会比较友好，他是通过探测内核中SQL执行阶段，将SQL执行耗时与资源做映射，分析出资源与SQL的关系，最终获得导致这次抖动的根因SQL，所以DBdoctor找出的SQL是根因SQL，直接按照诊断出的SQL去优化就好了。如下图所示：

DBdoctor优势

• 深度分析 - 深入数据库内核的全方面分析
  • 深入到数据库内核锁管理全过程，精准提示死锁和锁等待根因
  • 深入到数据库内核事务管理全过程，提供精确到索引级别的锁分析
  • 可视化展示死锁、锁等待、长事务，便于快速分析定位
• 精确诊断 - 精确到SQL级的性能洞察
  • 自研DRA算法引擎，精准提示根因SQL及等待事件
  • 对SQL按照资源瓶颈自动分类，快速提示资源卡点
  • 按访问来源进行SQL归类，快速找到问题客户端
• 便捷易用 - 可视化/极简交互、极致用户体验
  • 一屏展示资源－负载-SQL，轻松定位性能根因
  • 点击异常指标自动展示专家案例知识库内容示，帮助DBA更轻松的开展分析
• 非侵入接入 - 无需改动现有系统
  + 对数据库实例性能损耗接近零
  + 五分钟一键完成部署和对接，支持对私有云、公有云上的存量数据库实例快速纳管

应用场景1—出现故障时快速定位和诊断

某日，A公司在线直播系统的监控后台实时报警增多，开发人员怀疑是数据库性能问题引起的，但由于数据库日志非常多，经多个小时定位未找到问题根因。
同样的场景，使用 DBdoctor 工具后，开发人员在页面简单 4 步操作，一分钟内就发现了根因并完成修复。
(1) 框选出问题的时间段，在“关键资源指标”曲线发现有 CPU 猛增的现象；
(2) 对比同时刻的 AAS 曲线，发现活跃会话数远超 Max vCPU 水位线，找到其中影响最大的事件“Creating sort index” 如下图所示：

(3) 在该事件对应的“SQL关联分析”列表中，找到根因SQL；

(4) 点击专家文档，查看 Creating sort index 事件的解释，发现需要对 SQL 创建合适的索引或者 SQL 改写。开发人员按照修改后该条 SQL 耗时从 30s 降到毫秒级别，问题得到了解决。

应用场景2—历史问题回溯定位

公司电商系统的开发人员上班后发现昨晚有会员服务异常引发了用户投诉，初步怀疑是数据库锁的问题，但不能确定具体是哪个事务引发的，问题分析中断。
使用传统数据库工具对此类问题的分析收效甚微。而利用 DBdoctor 的 SQL 审计和锁日志功能，能够不遗漏事发现场的任何一条数据库信息，最终揭示出问题根因。
(1) 通过查看 AAS 历史曲线发现，晚上 11 点有持续十多分钟的时间，活跃会话数达到 411，远超 Max vCPU 水位线。其中影响最大的事件为“Waiting for global read lock”，表明在等待全局读锁
(2) 通过 DBdoctor 的锁透视拓扑图，查到锁等待的源头事务以及对应的 IP 地址。开发人员沿着源头 IP指向的节点，发现了定时备份任务的脚本。通过优化定时任务脚本，后续线上未再出现锁现象，问题得到解决。

应用场景3—通过巡检提前发现问题

公司财务系统一次版本升级，对数据库进行了表结构变更。升级第一天的自动化巡检中，DBdoctor 发现CPU 高峰期占用达到 69%，超过预设的警戒线，触发了告警。此时，业务系统并未有异常反映。
(1) 运维人员在收到告警邮件后，打开 DBdoctor 的观测页面，发现在该时段 AAS 曲线展示的活跃会话数有突增，但未到达 Max vCPU 水位线。
(2) 通过页面的一键对比功能显示，活跃会话数相比版本升级前有大量增加。关键 SQL 关联分析显示，新版本耗时最长的 SQL 单条执行时间为 9s，并发数 30+；
(3) 按照该 SQL 对应的经验文档指引，研发人员发现了该 SQL 的问题在于未正确添加索引，并紧急进行了修复。由于当时业务的并发流量不高，暂未影响到线上业务。但此问题如果没有及时暴露并解决的话，在接下来的月底业务高峰期时，更高并发的冲击下，必然会引起服务接口的超时响应，影响到账款结算等关键业务。

关于我们

聚好看科技是海信集团旗下的互联网科技公司，以云计算、大数据与 AI 技术服务 B 端行业客户，连续五年获得“独角兽企业”称号。先后承担国家级项目 10 项，相关科研成果“支撑千万级用户的智能设备云平台及其应用”“JuDB 云数据库 PaaS 平台”经鉴定达到国际领先水平。
聚好看研发团队的核心成员来自阿里、华为、腾讯、EMC 等国内外一线科技企业，在数据库、云计算领域有着深厚的技术沉淀和实践经验。我们致力于通过持续的技术和产品创新，打造业界领先的云数据库产品。

产品可以在官网免费下载使用，这是我们的产品官网：http://hisensecloud.com/
我们也在招人，希望数据库达人可以加入我们一起让数据库使用更简单、高效。