DBA不仅仅是管理数据库--也要管理中间件

看到这个标题可能觉得我在乱说，其实很多中间件作为数据库的上下游，它们的稳定取决于数据库的稳定。这里我主要指的是SQL。

很早之前我说开发的主题语言其实更多的是SQL（这里并没有说Java不重要的意思），只是Java中并没有太多的业务逻辑。真正的业务逻辑主要还是在SQL中体现的。说的直白一点是如何写数据，如何读数据。

我现在工作不太做数据库安装、备份等。更多的是看看开发这里的问题。用工具打开开发代码看到后很多项目一半以上是SQL，甚至这个比例最高能到70-80%。所以更加证明了我之前说的。

每当说到这里非数据库出身的开发会质疑我夸大数据库的作用。因为我也见过有人是把数据全部拿走，然后自己在程序中做各式各样的运算等操作。这样显得和数据库没什么关系。其实这个作用自在人心吧。

但是在一次次数据库问题甚至故障后，越来越多的开发人员意识到我说的是对的。而我也在一些顾问和问题中发现，其实SQL的影响不仅仅是数据库。多次中间件（这里指的是Tomcat的JVM和消息队列等）的问题（OOM或者是频繁Full GC）也是由于SQL造成的。因为一次取的数据太多，数据库把数据明细这种几十万甚至上百万的数据送到相关环节，这些环节一下处理不了这些数据，就发生了OOM或者是频繁Full GC。

这里可能是一次性取很多数据，也可能数据看上去不对但是数据的对象很大。总之是数据占据空间很大，导致了问题。

上周一个开发主动找我说。他们的JVM中问题80%都是Full GC，而这些最后发现全是SQL导致的。就相关问题找我咨询解决方案。这说明越来越多的开发人员开始觉醒了。这真的是好事情。

我想起从前我在一个单位，和一个开发说你这样写不对，有什么什么问题。结果大家应该能猜出来，谁理我啊？但是后面有一天，那个开发找我问问题，问的还是比较深刻的问题。后面工作时遇到问题就来问我。我很好奇怎么会有这样的改变。后来我才得知他去一些比较好的公司面试，技术面的问题就是我平时说的。结果他因为不知道，错过了机会。回来以后真的是发愤图强后，然后果然去了比较好的企业，而且还换过公司。现在收入应该增加不少了。

我第一家公司小，但是当时管研发的都是70后。招聘看的是计算机知识、算法、数据库，最后看编程。招聘的开发人员真的素质都很高。可能几个人就做一个大项目。

现在的招聘是只看编程（用什么框架）和技术栈和参与项目。我也遇到过问开发这个数据从哪里来？答：不知道我调接口。再问这个数据去哪里？答：不知道我调接口。你知道为什么要用以及怎么用Redis，为什么要用以及怎么用ES吗？答：不知道我调接口。

对开发易用是好事，但是开发也应该知其然和知其所以然。当然如果每个都说精通源码的那种了解我觉得是过了。我个人觉得尺度应该是能知道问题在哪里？比如开发人员知道是数据库这里问题和中间件这里的问题。然后知道是什么原因导致的就行了。剩下的交给专业数据库人员来解决，给出解决方案就像。

管好数据库和中间件是DBA（administrator）到DBA（architect）的阶段。