这是一个非常具有争议的话题

估计人群有
A：支持的。这种以我为代表的一批人。觉得不管不行，迟早战火会烧到数据库这里。
B：不支持但是也不反对。觉得自己就是应该逆来顺受的。也喊出来一种道义上的制高点。技术是为了业务服务的。
C：反对的。有些一直觉得开发应该取代DBA的。觉得不配去管理。
D：各自管好自己就行。不要越界。诚然如果一个团队每个人都完成自己的分工，能自扫门前雪也行啊。但是实际上，几乎都是要去补位。这种其实都有。就看谁多了。

节后第一天接到别人求助说，他们的Redis堵塞了。（说到这里，顺便说一下，不少人觉得Redis、ES等不算数据库，这点我始终不认同。凡是DB-engine上有的都是。反而Oracle的OGG，纵然是甲骨文的产品，纵然是连接多种数据库的桥梁，我也不认为OGG是数据库）

Redis的堵塞不常见

这里的堵塞我其实也是第一次见。这个是在client信息中出现了blocked_clients。出现了27个。
从数据库角度看这个堵塞可能最先想到的是slow-SQL。看了一下确实有，但是他几乎不更新。我尝试删除了几个堵塞的会话，然后他又恢复了。还是27个。很奇怪是吧？

最后我发现是应用程序的设计问题

27个大的列表，不断的写入和读出。你可以理解为一个消息队列。虽然说Redis支持消息队列的这种应用。但是吧。支持也有个前提条件。毕竟不能当做kafka用。

就像数据库的多模是可以解决异构数据库的融合，但是极致的应用的话，还是差点意思。这就像不少数据库说兼容谁谁谁。但是如果是深度应用的话，还是不行。这种深度不是说使用了存储过程就是深度。10行的存储过程，那叫兼容。10万行的存储过程，那叫深度应用。

所以我一般和人交流，有的企业说我们已经不让用存储过程了。好像不用存储过程就不深度了。结果SQL写的复杂的不亚于存储过程。

我们说的多模是通用场景的。那么如何才能把握这个度。显然开发人员未必熟悉，甚至可以说几乎不懂。因为关注点是业务逻辑。所以怎么用，还是DBA更加有发言权。

数据库就像一个产品，他有他的说明书。遗憾的是开发人员不看。其实即使DBA也未必全看。但是还是有人看的。当大家遇到问题时候，要么问人，要么看说明书就是这样。

有时候的灵魂拷问

有时候开发人员会问，这个字段可以吗？这个表可以吗？这个索引可以吗？我会一一作答，问你这个场景是什么？需求是什么？以后打算怎么扩展？怎么操作数据和怎么检索？

然后我会指出，这样的话，不能这样做，应该如何做。之所以这样是一次次的教训让大家知道，不这样就会出问题。

对于看不起数据库和DBA的人来说，为什么要设计这么复杂的产品和说明书？

那就去看看法律，各种法律各种条款也不少。那怎么不简单一点？法律我不擅长，只是知道多一个字和少一个字都不行。有些东西不是设计者不想简单，是情况太复杂了。

笔者认为不仅要管还要从源头管

如今数据库有RDBMS和NoSQL，以及NewSQL。再加上国产数据库等，已经数不清了。DBA应付这些都已经很吃力了。这些上面的坑和最佳实践还是DBA相对了解的最清楚。所以最佳的解决方案还是从源头开始管理开发任务。

除此之前还要卷中间件、硬件、消息队列、操作系统等。这些领域作为数据库的周边，开发人员深入的程度可能还不及数据库。使用不当和用错，不说是板上钉钉吧也可以说十有八九有问题。各式各样的妖孽问题层出不穷，最后还会使得系统的成本上升。

你认为应该管吗，欢迎评论区留言。