怎么拯救一个不大靠谱的数据库系统 （5 不靠谱的前生）

这期有点类似于星球大战，拍完了在弄一个前传，实际上是有必要说说一个不靠谱的系统是怎么产生的，虽然创造者本身估计也不愿意这样，那到底这样的系统大约是怎么产生的。

首先要确认的是，不是每个公司都是阿里腾讯美团百度有明确的规划或者一堆牛人在掌舵把风，产生垃圾系统的前期可以归结为需求，一个需求不靠谱，如地基没打好，可想而知在其上面的东西的稳定性有多高，需求分为，可变和不变的两种，当然将所有的问题都归结于需求也未免有点不在自身上找原因，这点的分两段来说。

1  有些公司在项目初始阶段，不会有DBA，因为他们从来没打算让这样一个人来存在，或者他们认为DBA 就是运维，不配参与到项目中，在或者就是根本请不起一个DBA，所以不少公司的项目80%或者更多的，基本上都是开发人员主导，数据库就是一个赶鸭子上架的东西，加之早期数据量不大，或者这个项目死活未知，所以数据库哪里有人顾得上考虑你的存在。

这里软件架构没人管，数据库怎么安排没人知道，可能在系统上线的前一刻，还在纠结各种各样的BUG。  

当然这样的系统上线后，不出问题的几率很大，因为根本没有数据量，没有数据量的系统，如同用纸糊房子，只要不下雨不刮风，看上去也是很美的。

2   一个人说了算，这里一个人说了算的意思，开发架构数据库硬件，乃至一些需求的分析都是一个人说了算，即使是有经验的人员，将所有的一切都让他一人处理，这也不大可能做出一个尚且可以良好的系统，每个专业都有自己的特点，都有自己的硬实力的东西，一个人怎么可能掌握着一切，但不少单位初始的情况大多是一个人说了算，在一个人有限的经验，和有限的经历下，创造一个好的系统的可能性微乎其微，剩下的就是在系统成型后，每天惶惶不可终日的怕系统出问题。

3  没有视技术人员和技术人员的培养，不是所有的技术都可以买来，卖给你技术的公司会留一手，或者三手四手，不懂技术，身边没有懂技术的人，自然购买软件产品和服务的时候，被“欺负”是在正常不过了，这是不少单位，在购买软件和服务后，发现还是玩不转了的一个原因，然后就是更多的续费更多的技术黑洞，这可能是大部分企业的现状。

4    干一天算一天的技术工作者，实际上技术工作者本身也是需要反省的，自己的技术是不是老旧，学习先进经验只是学到了皮毛，而没有将本身这项技术弄清楚搞明白，天天假大空的口号喊着，各种技术名词的堆叠，纸房子只能远观，不能近看，只要有懂行的稍微的看上几眼，就要被吹到，不少问题上技术应该分门别类，没有万金油的技术人员，对某项技术钻研深的人员，必然有没有钻研过的技术。而如果工作中的技术环境，要你假大空，自然会把专业的人才一个个的挤走。

当然还有更多的原因无法通过语言正式的表达，这里就略去了。说到这里，到底这篇文字和数据库还有什么关系，当然有关系

一个系统的好坏,不是数据库系统本身说了算的，而数据库很可能是一个,各种垃圾堆积后，性能爆发的危险区域。数据库无法承受并发，数据库在所在的服务器上，耗尽了服务器的物理性能资源，各种垃圾的语句导致系统没有响应，各种不入流的设计，终让数据库呈现出，一会死锁一会BLOCKED的精彩场面，然后将问题归咎于数据库。

呵呵，不用笑，懂得我话的那些 DB 从业者笑不出来，每天都在被蹂躏，这就是一个个垃圾数据库系统产生的种种起源，然后将责任一股脑的泼洒到数据库不稳定,垃圾就是这样产生的。

这就是一个垃圾系统数据库的诞生的前因后果，既然我们无法阻挡这样的情况发生，自强自救就是必需品了。(怎么拯救系列结束,当然也可能是另一个系列的开始,怎么自强自救)