为什么我们需要一个 SQL 数据库审核平台

2018年6月4日，链家 40岁程序员删库，公司斥资 18万恢复系统；

2020年2月24日，微盟程序员删库跑路，次日股价下跌 21.5亿人民币；

这些安全事故，暴露出大部分公司的隐患，缺少一个完善的数据库审核平台。数据库所有的操作，都应该有其审核规则，来确保不会造成灾难性的事情发生。

比如删库，一旦审核平台接到 Drop Database 的命令，就立马出发邮件到主管，申请批复，并暂时性停止执行，直到收到回复批准。

本文探索数据库审核平台的功能和实现。参考书目还是《数据库高效优化：架构、规范与SQL优化》

再举个例子，来说明下审核平台提供的功能。

比如，有 CRM 用户反映，平时 1,2秒就能打开的客户利润报表，现在需要 20 秒了。经过前端组的排查，确定是数据库的 SQL 返回结果慢了，请求 DBA 调优。

DBA 于是在审核平台，建了这么条规则：抓取运行时间超过 20 秒的所有 SQL 和存储过程，包括详细的 SQL 文本，索引使用和执行计划。

等待一段时间，平台就会把这些超长的 SQL 抓取出来，DBA 筛选下，就能定位到问题。

数据库审核平台的功能，到此就很清晰了，提出问题，设定规则，抓取问题SQL.

有同学会疑惑，这不就是问题排查嘛，造一个平台来解决，是不是大材小用？用短小精悍的脚本，不香嘛？

当然不是！我用 3 个节拍说服你

SQL开发的苦恼

SQL 开发小哥哥和小姐姐，平时被业务开发掏空。考勤，OA，HR，生产制造系统，ERP，进销存，仓储等 MIS 系统，通常三四条线，同时开工，占据绝大部分时间与精力。

忙起来，上午写的SQL，下午都能忘记逻辑。好不容易闲下来，除了开黑，看剧，社交，解解乏，根本没有时间再投入系统学数据库。

长期以往，遇到某张大表，SQL性能直线下降时，他们将束手无策。当靠经验，加索引，改写SQL均无效时，他们只能求助于DBA。

DBA的无奈

业务越丰富，头疼的当然不止开发，还有DBA. 成熟的企业，往往使用四，五种不同架构的数据库，十多套不同厂商的商业数据库。比如Oracle, SQL Server, DB2,MongoDB, ElasticSearch 等等。

安装，调试，建库建表建索引，建高可用集群，这些琐事，已经让 DBA 应接不暇。据我所知，传统行业还不配备专职 DBA，他们往往兼顾一些报表开发，ETL设计和建模。

于是，他们的命运，也就剩下疲于奔命，现场救火。此时与开发并无不同，没有紧急的工单，有问题的SQL调优，就被安排到了猴年马月。

上帝欲让人疯狂，先使人疯忙。

数据增值小分队

近十年，云计算不断介入后端。越来越多的机械性管理工作，被云统一筹划和部署。使得更多的精力与时间可以投入数据资产的管理，比如数据治理，数据质量和数据安全。

云之前，DBA 团队面临的情况：出了系统性能故障， DBA 的锅；出了数据库连接超时，DBA的锅；甚至数据质量问题，都是DBA的锅。但是一旦业务猛增的时候呢，嗯，各种领奖，嘉奖，都是前端业务系统的。

当 DBA 团队不能成为资产时，就会沦为成本。成本，是要被剔除的。因此，数据增值分队应运而生！

让上帝的归上帝，凯撒的归凯撒

SQL 开发会渐渐与前端框架融合，探索和保障业务系统顺利展开。DBA 分队，提供信息架构的基础建设，保障存储的安全，计算的稳定。在企业上云或数据库自治后，让大量基础 DBA 人员转型到数据增值团队来，负责数据治理，数据分析和数据安全等领域。

以上三点，就是我们需要数据库审核平台的理由了， 它帮数据团队，把服务做到量化，可视化、规模化和利润化。

数据库审核平台实践

那么，我们怎么做一个数据库审核平台呢？

购买软件，还是自研？购买的软件能帮我们解决所有的问题吗，这些数据带来的问题，有通用的模式，可以用统一模型来解决吗？

回答这个问题前，让我们先取个经，看下别人的成果。

• 一梯队，BAT等互联网一线大厂。它们的方案，完全自研SQL引擎。实现 SQL 执行成本分析，自动审核，访问分流等。

• 与大厂提前自动审核不同，大多数没有自研SQL引擎能力的中厂，选择半自动方式，做到事后审核。方法是收集数据库各项指标数据，引入人工判断，做好审核。

• 针对完全没有研发能力的小厂，那么只能依靠购买商用的软件产品，再辅以人工处理。缺点就太明显，价格高，而且扩展性不高。

普通的团队怎么办呢，保二争一。自研适合大部分团队。

用 2 张图来表达，第一张是架构图，第二张是操作流程图：

平时开发中，经常遇到这些异常：

• 上一秒运行正常的SQL，这一秒抛出了日志文件空间不足，执行失败
• 平常运行秒出的SQL，今天偶然特别慢，就像人睡觉睡的好好的，突然抽了一两下，原因未知
• 平静的出奇的某天下午，突然有同事大叫一声，谁XX把我的报表进程给杀了
• 一天中的某段时间，数据库就像僵住了一样，无论运行什么都很慢
• 系统中总有几张表，涉及到他们的查询，就非常慢
• 每天都要手工清理一些表、索引或视图等数据库对象，没有时间和精力投入数据建模，数据治理

这些常见问题，归纳为两类：

• 数据库对象
• SQL 审核

也就是图中的 SQL 管理和 DB Object 管理。数据库审核平台主要做这两类。

回顾开头的原理图，数据团队要做的事情，无非就是：

• 定义问题
• 规则设计
• 编码实现

如果大家有兴趣，可以参考宜信团队开源的 CreditEaseDBA Themis 数据库审核平台，在此基础上，加入自研的功能。他们的产品地址是：

https://github.com/CreditEaseDBA/Themis

再次申明，本文灵感来自《数据库高效优化：架构、规范与SQL优化》，摘录部分观点和示意图*。