NineData 把多数据库慢查询定位和优化串联起来

路径熟悉

较难集中处理多库

下载 slow log 文件离线分析

看起来可留档

原始日志分散，协作效率相对有限

只看单条 SQL

上手快

不易看到模版级共性问题

事后口头总结优化点

成本低

较难形成持续治理

人工查看慢日志，为什么会在多库环境里逐步失去效率

仅数据库数量超出几台时，人工方式的局限便会颇为显著。一个业务应用常常不仅有一个数据库实例，并且存在生产、预发、测试以及环境上的差异，再加上主从、分片以及不同业务模块的独立库，一旦问题出现，DBA难以借助人工方式迅速回答“究竟是哪个库、哪个模板、时间段是哪个、哪个用户的慢SQL在致使延迟增大”。原始日志固然仍留存着，然而它们并非以适宜协作的形式呈现。

慢日志排障并非仅为 DBA 一人之工作，是需进一步予以关注的，研发得去确认业务路径，运维要留意实例状态，架构师或许要看整体流量之变化，就连产品与业务也会追问修复进度，倘若慢日志依旧主要由少数熟知数据库之人去人工获取以及解释，那么数据库团队便会成为整个链路里较为集中的压力点，工具未集中化，沟通成本自然而然将会明显增高。

NineData慢查询大盘

NineData的价值，并非去替代数据库原有的日志，在于将那些日志从原始材料转变为可协作的分析对象。具有慢查询趋势的数据图示，能让团队首先看到随着时间产生的变化，通过SQL模版聚合，能让大家先去找出“哪类问题更值得优先予以查看”，进而再深入到具体的语句、执行的用户、返回的行数、执行所耗时长以及诊断建议。这种工作方式相较于直接去翻看日志所更具价值的地方，并非体现在界面方面，而是体现在认知的顺序上：先是查看模式，接着查看个案，随后再进行优化。

NineData的慢查询大盘，具有这样的功能，即支持按照数据源来进行查看，支持按照环境来进行查看，支持按照标签来进行查看，支持按照数据源类型来进行查看，通过这些查看方式，能够清晰地看到各数据源所产生的慢查询情况。

NineData慢查询统计，它能显示，该数据库在某个阶段所产生的慢查询详情信息。SQL模版指的是，不包含具体参数的SQL框架。使用相同SQL模版的慢查询，会被记录在同一个模版下。展开模版之后，可以看到相关慢SQL语句，其所包含的信息也较为完整，比如执行时长、查询时间、执行查询的用户、主机名称等。

这会明显地使团队协作的方式产生显著改变，以往研发与 DBA 针对慢 SQL 展开讨论的时候，通常是在发送零散的截图以及日志片段，当下能够围绕同一个 SQL 模版以及同一条诊断链路来进行讨论。

慢日志分析接下去怎么做

许多团队并非没有能力去查看慢日志，而是欠缺能力将慢日志持续转变为优化行为。看见一条慢SQL仅仅属于起点范畴，更为关键的是后续这几步：能不能较为迅速地判定执行计划出现了何种问题，能不能察觉出是不是索引运用欠佳，能不能辨别出是不是数据量增大或者SQL写法不合理，能不能使同类问题在往后较少出现。要是没有后续行动，慢日志就仅仅只是一份迟到的事实而已。

NineData的诊断优化页面，会针对那些慢查询的SQL语句来开展性能诊断作业，性能诊断所产生的结果涵盖执行时间过长这一情况，还有有效读较低的状况，以及等待时间所占比例偏高的情形，另外缓存命中率低下也包含在内；规范审核是依照admin配置好的SQL开发规范针对SQL语句实施审核行为；索引建议靠CBO成本代价模型来给出索引推荐，以此助力DBA能够更有效率地对数据库性能予以优化。

慢查询报表于NineData进行下载：此功能是当我要把对于优化的需求提交给从事开发工作的人员之际较为实用，于数据源慢查询详情页面当中能够把目标时间段关联的慢SQL集成到一份PDF文档内，这里面涵盖了相关整改的详细情况信息，以此方便开发人员对照着进行优化。

NineData 将性能诊断、规范审核、索引建议以及报告下载，全都放置于慢查询分析路径当中，核心价值也就是于此所在，它是于向团队发出提醒，慢日志并非是那种一次性的异常分析材料，而是应当深入到日常优化循环里，能够把慢日志采集分析串联构造成协同流程的人，就越具备将数据库性能问题从“常常处于高频被排查状态”转变成为“持续趋向于收敛的工程问题”的可能性。

值得把这件事重做

业务越是实时，数据库数量越多，团队中多人协作的情况越频繁，慢日志排障就愈加不能再依靠人工串联起来。此应用性能方面的问题原本就要求反应迅速，协同高效，得出结论快速，然而人工查看 slow log 恰恰是相对耗费时间的一个环节。企业更为需要的并非是更多的日志，而是能够更快地将日志转化为可执行判断的那种能力。此判断对于企业而言，是极为关键的，它能够让企业在复杂的业务环境中，迅速做出正确决策，避免因决策延误而导致的各种损失，从而在激烈的市场竞争中占据有利地位，实现可持续发展。

对 NineData 进行补足的，所针对的并非是一个日志页面，而是将“采集—定位—诊断—优化”这一系列流程，重新设计成为适合企业数据库团队日常使用的工作流。

NineData 慢查询分析的呈现形式也极为契合排障现场，平台默认展现最近 12 小时的慢查询趋势图，且在详情页面中默认留存最近 3 天的慢查询记录；外层依据 SQL 模版进行聚合，内层能够展开从而看到具体的 SQL 语句、执行库、执行用户、返回行数以及执行时长。多个人一起协作时，这要比DBA人工登录进数据库去查看mysql.slow_log，或者按天把日志文件给下载下来更加便利，原因在于，围绕同一组“模板级问题”去作讨论，研发、DBA以及架构师会变得更便利，而不像围绕逐个分散的、原始的日志那般，每个人都各说各的话。

总结

慢日志采集分析所要解决的，并非仅仅是“找出哪条 SQL 慢”，而是要达成多数据库、多环境、多角色都能够依据同一套事实，迅速定位瓶颈、判断原因并且持续进行优化。能够将慢日志采集、模板聚合、性能诊断、索引建议以及团队协作整合进同一条协同流线之中的，才更契合企业当下所急需的数据库性能治理平台。

相关标签： # NineData # 慢查询 # 数据库优化 # 性能诊断 # 团队协作