放假第一天，就收到别人帮忙说他们的Redis被屏蔽了。 （说到这里，顺便说一句，很多人认为Redis、ES等不算数据库，这一点我一直不同意。DB-engine上的一切都是。相反，Oracle的OGG，尽管它是一个Oracle产品，尽管它是连接多个数据库的桥梁，我也不认为OGG是数据库）。

Redis的堵塞不常见

这其实是我第一次看到这里拥堵。这是因为客户端信息中出现了blocked_clients。 27 出现了。从数据库的角度来看，当看到这种阻塞时，首先想到的可能是慢SQL。我查了一下，它确实存在，但几乎不更新。我尝试删除一些被阻止的会话，他又恢复了。还是27岁。很奇怪吧？

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

27 个大列表，不断写入和读取。你可以把它想象成一个消息队列。虽然Redis支持消息队列的这种应用。但就这样吧。支持也有先决条件。毕竟不能当kafka用。

就像多模式数据库可以解决异构数据库的集成，但就最终应用而言，仍然几乎没有意义。这就像许多数据库说它们与某某人兼容一样。但如果是深度应用的话，还是不行。这个深度并不意味着使用了存储过程。 10 行存储过程称为兼容的。 10万行的存储过程称为深度应用。

所以我平时跟人交流，有的公司说我们不再允许使用存储过程。看来不使用存储过程就没有深度。因此，编写SQL 并不比存储过程简单。

我们所说的多模是针对一般场景的。那么如何把握这个度呢。显然开发者可能不熟悉它，甚至勉强理解它。因为重点是业务逻辑。所以DBA对于如何使用它有更多的发言权。

数据库就像一个产品，它有它的说明。可惜开发商不看。事实上，即使是DBA 也可能看不到一切。但还是有人在围观。大家遇到问题的时候，要么请教别人，要么看说明书。

有时候的灵魂拷问

有时开发者会问，这个字段可以吗？这桌子还好吗？这个指数还好吗？我一一回答，问你这是什么场景？有什么需求？未来打算如何拓展？如何操作数据以及如何检索数据？

然后我会指出，在这种情况下，什么是不能做的，以及应该如何做。之所以这样，是为了一次又一次的给大家教训，不然就会出现问题。

对于那些看不起数据库和DBA的人来说，我们为什么要设计这么复杂的产品和指令呢？

然后看看法律。有许多不同的法律和条款。为什么不简单一点呢？我不擅长法律，我只知道多一字或少一字是不够的。有些事情不是因为设计者不想简单，而是因为情况太复杂了。

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

当今的数据库包括RDBMS、NoSQL 和NewSQL。再加上国内的数据库等等，更是数不胜数。对于DBA来说，应对这一点已经非常困难了。 DBA 对这些陷阱和最佳实践相对熟悉。所以最好的解决方案是从源头管理开发任务。