这是学习笔记的第 1922 篇文章
最近把慢日志的流程做了下梳理，其实这个体系已经是比较清晰了，不过我的设计思路和行业里使用的慢日志方案有一些不同。我会给出一些这么设计的原因。
首先慢日志的需求定位可以参考之前的一篇文章。
当时列出了一些计划，但是没有给出一个较为清晰的步骤，我们画一张图来说明一下。
如果你的数据库部署在多个IDC中，很可能是使用多个IDC的备份服务器，我们可以统一慢日志的目录和命名规范，这样慢日志的处理方式就是完全相同的逻辑了。需要说明的一旦是慢日志在数据库侧是不做分析的，只是做文件的转储。分析的工作是在备份服务器上进行，我们使用了pt-query-digest完成主要的分析工作，这是个设计慢日志分析平台的一个基础功能，pt工具支持json格式和hist模式的数据落盘，我们可以指定一个数据源，pt工具会将分析的结果转储到库中。
在这里我们所做的一个较大的改进是我们在备份服务器的主要任务是将pt分析的结果建立新的模型。
这里会有几个相应的数据表：
slowlog_snapshot 这是一个重要的表，也是基础表，我们的慢日志分析默认是按照周期来抽取的，比如半个小时，我们可以理解是一个快照。在这个快照范围内的数据都会以快照为单位进行存放。假设现在是10:00，那么下一次的快照时间就是10:30，这是周期性任务，而对于实时的日志分析，流程不会变，但是从快照上就会有差别，比如在10:20生成了一次快照，如果之后的查询是在符合的时间范围内，那么我们就不需要反复的做日志分析了。 一般来说，半个小时为单位的慢日志足够用了，而如果我们没有快照的概念，那么开放给业务的都是实时查询，其实从数据分析和处理来说都是一种较为盲目的状态。
有了快照的概念之后，我们会建立一系列其他维度的表，这些也是基于pt解析的慢日志报告中的部分。
比如pt解析的慢日志报告，下面的一些内容可以建立额外的几个表来存放这些相应的信息。
目前建立了4张表来存放这些信息，所以整个模型的部分就会是如下的样子：
这样多个IDC的慢日志解析都可以并行完成，而不需要彼此依赖。在服务端可以对一些服务做一些流量控制，比如半个小时生成了太多的慢日志，那么我们可以解析一部分，而不需要全部解析，如果SQL有重复的，那么我们也可以做下去重，同时也可以对频率进行控制，比如1分钟解析一次，其实我们就可以在服务端做下配置管理。
总体来说，是让整个慢日志管理是一个体系化的，在完善了这个模型的之后，后续的是一些更有意思的分析工作，对于整个慢日志的价值产出会是一种最大化的体现。