说起这个事情，大多数人有两个反映，如果是运维人员，或者DBA，倾向性将怀疑的指标，指向开发，性能不好的SQL ，存储过程，滥用的TRIGGER ，和 函数，数据硬件的性能问题。 而开发人员，则多数会想到， 硬件的问题，数据设置是不是有问题，性能不好的SQL。

想是大致如此，数据库性能为什么不好，个人觉得有这几个方面（并非有次序，每一个问题的错误选择都会导致数据库性能不好）

1  数据库选型错误

2  数据库软件配置项问题（数据库参数）

3  硬件问题，如内存过小，I/O性能差，CPU 核心数，多线程不支持

4  操作系统的问题和限制

5  过度依赖数据库

6  不好的SQL 语句，及不符合选择数据库的SQL使用方式

7  超过预期使用数据库

其实使用数据库可能引起性能不好原因，到导致整体应用性能低下的问题来看，数据库的使用是一门综合性的学问，并非将上面的任何一点做好，就能保证数据库不出问题。 大家都熟悉的木桶理论，只要有一点做不好，性能的问题就会出现，越多的点做不到，则出问题的几率和严重性就会越高。

这就引出了，两个概念，数据库容器化，和数据库程序化，这两个概念将数据库的使用，拉向了两个极端，一个将数据库作为仅仅工程序存储，和调用数据的 “水盆”。 DBA 的工作仅仅就是关注数据库的物理特性，而将所有的对数据库的复杂操作都在程序端完成。数据库的地位变得无足轻重。

而另一种对数据库的使用，则是将数据库作为“奶妈”，离开一时一刻都是不行的，程序变为了一个空壳子，真正将整个系统撑起来的，是数据库，任何一个，存储过程，TRIGGER, 函数的失效，都能让整个系统一团混乱。

多年的经验，其实这两种使用数据库的方式如果要进行类比的话，就是典型的ORACLE 和 MYSQL ，对这两种数据库的使用类比。

ORACLE 可以支撑丰富的系统函数，存储过程，各种数据表格的特性，程序可以变得不再重要，所有的东西都在数据库中的存储过程 ,VEIW, 函数，中帮助程序计算。 显而易见，如果数据库有什么闪失，则“儿子”，就很有可能挨饿，没人照顾。

而另一种极端的使用MYSQL的方式 ，如同继子和后母的关系，如果程序在半小时与数据库失联，数据库已经崩溃了，而程序还和没事人一样，撑上半小时继续工作，或者更长的时间，想来程序和数据库的关系是有不紧密。

这两种开发的方式也就是我们现在看到的，传统开发和互联网开发。这两种开发方式并没有 “好” “坏” 之分， 每个成型的开发方式，都有他不为人知的“背景” 和 “故事”。 如果单单拿出，说那种好，那就有点幼稚园了。 

倒是觉得折中的方式更让人感到舒服，适度的依赖数据库，发挥数据库本身的特色，将开发的工作量，复杂度降低，这是一件提高效率和降低成本的好事。

多种数据库混合完成工作，在当前各种数据库种类爆发式发展的年代，越来越被理解，显然，将所有的数据都放到一种数据库，已经是要过时的做法，。发现每种数据库的优点，善于利用，对比现在程序中，大量使用，  MQ 消息队列，REDIS, Kafka ,zookeeper，有一样的意思，程序也不在是单独的程序，而是要依靠框架，组件，消息队列，集中式缓存，或者程序内部的缓存，将程序的复杂度降低，完成一项项单独用程序无法单独完成的工作和性能要求。

数据库无非也是一堆程序组成的一堆数据库结构（可以读写），加上一些漂亮的界面，各种数据库自己处理这些数据库结构中数据的方法，提高数据库提取数据的性能和功能而已。

扯得有点远，拉回话题，在DBA 界，一直就无休止的对比各种数据库的性能和要分个高低，在同样的硬件下，到底哪个数据库，功能提供的更多，性能更好，对开发人员更友好，哪个数据库的成本更低，等等就是 DBA 界乐此不疲的话题。

相对国内有些论坛的比较有时没有什么技术底蕴，最终引起最低级的“交流”，国外的某些网站上的东西倒是很有意思，各种功能的对比，和现身说法。

比较国内，MYSQL 和 POSTGRESQL 打的火热，国外则是ORACLE 和 POSTGRESQL 经常被作为一对进行品头论足。

其实没有任何一种数据库可以取代，另一种数据库，数据库之间仅仅是竞争的关系，而决定那种数据库兴盛和衰败，是使用的场景，成本的付出，功能的特殊，行业的特性，程序调用易用性，等等......可以确定的这也不是一件单线程的事务。