现状

一般成熟的公司都会有DBA这样的角色，他们借助一些自研或开源的db相关产品，负责保证业务数据的高可用，同时统计和监控线上数据库的性能情况。我所在的公司就有 udc 、 idb 这样的产品。类似慢查询、性能监控这一块，它们能协助业务快速定位问题。

尽管如此，仍然无法杜绝线上慢查询的产生，快速发展的业务，花费很大的精力排查每个版本的潜在慢查询并不现实，只有不断提高业务同学对慢查询的认识以及对慢查询的分析能力，并提供一套高效且能易于使用的系统才能很好的减少线上慢查询，减少数据库的压力。

有些慢查询，新增了已有的大表查询纬度，然而没有及时添加索引，上线后直接出现慢查询，系统响应时间变长，如果不能及时处理，数据库的处理能力马上达到瓶颈，系统可能无法响应正常请求。另一些则可能是新的业务，随着时间的推移，数据快速积累，逐渐出现慢查询，轻则降低系统平均响应时间，重则导致系统不可用。

需求

线上慢查询，能否提前避免？能否提前优化 SQL 语句？能否快速找出所有新增的 SQL 语句？

为了达到这个目的,我们需要实现一套慢查询分析系统。接下来梳理整体需求，我认为应该从以下几个方面考虑。

1、接入成本

接入成本是首先要考虑的因素，系统能否推广，很大程度取决于接入成本，因此系统实现必须是方便接入的，同时应该尽量减少用户配置。

2、使用成本

需要定义系统的使用方式和流程，用户能够快速理解使用方式和流程。同时配合告警，通知功能。判定是问题 SQL 的时候，能快速定位到产生 SQL 的地方。能够记录问题 SQL ，后续能跟踪处理等。

3、系统扩展性

系统实现时应该有意识地考虑扩展性，使得后续能够快速支持新功能开发，扩展性包括但不局限于系统架构、代码组织；

4、效果量化

实现一套系统，需要量化效果，这样能更好的衡量系统的价值和决定后续的投入成本。系统实现的时候需要包含用户使用频率、问题发现次数等等的记录。