规则总分，跟规则配置关系很大。如关闭规则或将违反规则的阀值调低，都会提高分数。这要根据系统自身情况来确定。同一规则，对不同系统使用，其阀值是可以不同的。举例而言，数据仓库类的应用，大表全部扫描就是一个比较正常的行为，可考虑关闭此规则或将单次违反阀值、总扣分上限降低。
对象审核结果明细
这部分是对象审核的明细部分，对应每个规则其详细情况，可在左侧链接中进一步查看对象信息。篇幅所限，不做展示了。
执行计划审核结果概览 
这部分执行计划的概览展示，跟对象的情况类似。也是每种规则的扣分情况。
执行计划审核结果明细
这部分是执行计划的明细部分。
展开之后，可以看到违反每种规则的明细。上图就是违反全表扫描的规则的明细部分。
在上面是一些通用的解决方案说明。这里将可能触发此类规则的情况及解决方案进行了说明。相当于一个小知识库，便于开发人员优化。后面在平台二期，会做更为精准的优化引擎部分，这部分还会展开。
下面是每条违反的语句情况，我们可以看到语句文本、执行计划、关联信息（例如此规则的大表名称）等。还可以进一步点开语句，展开信息。
这部分是针对每条SQL的信息，包括语句文本、执行计划、执行特征、关联对象统计信息等。DBA可从这些信息就可以做一些初步的优化判断工作。
此外，平台也提供了导出功能。可导出为excel文件，供用户下载查看。这里就展示了。
10、我们遇到的坑在实际开发过程中，碰到了很多问题。我们这里简单介绍两个，例如：
MySQL在解析json格式执行计划中暴露出的问题…
【会话进入sleep状态，假死】
解决方法：执行会话之前设置wait_timtout=3,这个时间根据实际情况进行调整。
【数据量过大，长时间没有结果】
会话处于query状态，但是数据量很大或因为数据库对format=json支持不是很好，长时间解析不出来，会影响其他会话。
解决方法：使用pt-kill工具杀掉会话。为了防止误杀，可打个标识“eXplAin format=json”，然后使用pt-kill识别eXplAin关键字。
11、推进流程
此平台在宜信公司运行以来，为很多系统提供了审核报告，大大加快了数据库结构、SQL优化的速度，减轻了DBA的日常工作压力。在工作实施过程中，我们也摸索了一套推行方法。该平台已开源后，如有朋友使用，可参考实施。
收集信息阶段
海量收集公司的数据库系统的运行情况，掌握第一手资料。快速了解各业务系统的质量，做好试点选择工作。
人工分析阶段
重点系统，人工介入分析。根据规则审核中暴露出的核心问题，“以点带面”，有针对性的给出分析及优化报告。
交流培训阶段
主动上门，跟开发团队沟通交流报告情况。借分析报告的机会，可对开发团队进行必要的培训工作，结合他们身边的案例，更具有说服作用。
反馈改进阶段
落实交流的成果，督促其改进。通过审核平台定期反馈改进质量。有一定基础的团队，可开发平台，供开发人员自己使用。使SQL质量问题，不再仅仅是DBA的问题，而和项目中的每个人都有关系。