没有平台之前，DBA还是大量通过手工方式设计、优化数据库，其效率十分低下。特别是面对众多产品线、众多开发团队时，往往感觉力不从心。
公司自有团队人员上，还是以初中级为主，中高级人员相对较少。如何快速提升整体设计、优化能力，保证统一的优化效果成为摆在面前的问题。
正是有了上述多种的不平衡，促使我们考虑引入工具、平台去解决数据库质量问题。
我刚来到公司时，看到公司的这些问题，也曾考虑通过制度、规范的形式进行解决。一开始就着手制定了很多的规范，然后在各个部门去培训、宣讲。这种方式运行一段时间后，暴露出一些问题：
整体效果改善并不明显。实施效果取决于各个部门的重视程度及员工的个人能力。
规范落地效果无法度量，也很难做到量化分析。往往只能通过上线运行结果来直观感知。
缺乏长期有效的跟踪机制。无法对具体某个系统长期跟踪其运行质量。
从DBA的角度来看，面对大量的系统，很难依据每个规范，详细审核其结构设计、SQL运行质量。
面临上述这些挑战、现存的各种问题，该如何解决？
经过讨论，最后大家一致认为，引入数据库审核平台，可以帮助解决上面所述问题。
二、平台的选型 1、业内做法
在项目之初，我考察了业内其它企业是如何数据库审核的，大致可分为三个思路：
第一类，是以BAT公司为代表的互联网类公司。它们通过自研的SQL引擎，可实现成本分析、自动审核、访问分流、限流等，可做到事前审核、自动审核。但技术难度较大，公司现有技术能力明显不足。
第二类，是通过自研工具收集DB运行情况，根据事前定义规则进行审核，结合人工操作来完成整个审核流程。这种方案只能做到事后审核，但技术难度较小，灵活度很大。其核心就是规则集的制定，可根据情况灵活扩展。
第三类，是一些商业产品，实现思路类似第二类，但是加上一些自主分析能力，功能更为强大，但仍需人工介入处理且需要不小资金投入。而且考察几款商业产品，没有能完全满足所需功能的。
综合上面几类做法，最终确定我们采用“工具+人工审核”的方式，自研自己的审核平台。
2、我们的选择——自研
在启动研发这一平台之初，我们就在团队内部达成了一些共识。
DBA需要扭转传统运维的思想，每个人都参与到平台开发过程中。
过去我们积累的一些内容（例如前期制定的规范）可以作为知识库沉淀下来，并标准化，这些为后期规则的制定做好了铺垫。
在平台推进中，从最简单的部分入手，开发好的就上线实施，观察效果；根据实施效果，不断修正后面的工作。
结合我们自身的特点，定制目标；对于有些较复杂的部分，可果断延后甚至放弃。
参考其它公司或商业产品的设计思想，大胆引入。
三、审核平台实践下面来看看，审核平台的基本功能及实现原理及方法，这部分是本次分享的重点。
1、平台定位
在项目之初，我们就平台的定位做了描述：
平台的核心能力是快速发现数据库设计、SQL质量问题。
平台只做事后审核，自主优化部分放在二期实现。当然在项目设计阶段引入这个，也可以起到一部分事前审核的功能。
通过Web界面完成全部工作，主要使用者是DBA和有一定数据库基础的研发人员。
可针对某个用户审核，可审核包括数据结构、SQL文本、SQL执行特征、SQL执行计划等多个维度。
审核结果通过Web页面或导出文件的形式提供。
平台需支持公司主流的Oracle、MySQL，其它数据库放在二期实现。
尽量提供灵活定制的能力，便于日后扩展功能。
2、平台使用者
作为平台的两类主要使用方，研发人员和DBA都可以从平台中受益。
对于研发人员而言，只用这平台可方便定位问题，及时进行修改；此外通过对规则的掌握，也可以指导他们设计开发工作。
对于DBA而言，可快速掌握多个系统的整体情况，批量筛选出低效SQL，并可通过平台提供的信息快速诊断一般性问题。
3、实现原理