硬件一小步，软件一大步。

     今天又是一个问题，这个问题从数据库可观测性角度来看就是IO问题。数据库已经给出了建议（AWR）。这里说明一下：原来是物理机，后来迁移到虚拟机。我本人其实反对数据库在虚拟机中运行。虚拟机不配运行正式环境的数据库。这么说可能是有点情绪，但是正儿八经的系统，我还是建议不要用虚拟机。

     既然是IO问题，硬盘IO不是简单加硬盘就能解决，我想的就是增加内存。把数据尽可能在内存中处理。如果不增加硬件环境能不能解决呢？能，只是要改设计，而且要从头改。这在几乎每个公司都不太能接受。

     工作时间久了估计不少人也有同感，就是专业的给出解决方案有多种，有治标的也有治本的。治标的总体来说成本较高（因为属于危房加固，今天做点，明天做点。直到做不下去为止，最终还是要推倒重来。）  治本的成本当然也不低，就是直接推倒重来，节约的是不断加固的人力物力和财力。其实做事成本最低的方案就是一次性把事情做对。

     今天还和几个朋友说以前的一个故事。这个不是我身上的，只是听人说的。一个公司本来用的是Oracle，后来换成了一堆MySQL。要知道一个库拆成一堆库就是典型的成本上升。我本人既有Oracle MySQL ACE也有PostgreSQL的ACE这些，我没有说MySQL不行的意思。请听我慢慢说。结果出了很多问题，于是就从外面招来一个总监。在这个总监的带领下，问题逐渐收敛。

不过最后公司发现成本比以前高，因为总监太贵了。后来不要总监了，结果问题又开始多了。这个看似笑话的故事说明了，数据库其实没问题。使用的人有问题。我从这个故事中觉得那个总监应该是熟悉这些数据库，指导开发如何做。那个公司出现了返工甚至倒退的问题就是缺乏懂的人来指挥，后来有人懂但是嫌人家贵。

    其实很多时候我和那个总监差不多，告诉大家如何做是对的。只是环境未必允许，那么系统只能不断加固打补丁。

    事情分两头，那么如果一开始就错了。（注定无法一次性把事情做对）怎么办？那就只能用硬件抵消之前错误的代价了。  除了Oracle有exadata以外，可以看到Polardb、浪潮、华为都有一体机。这就是硬件带来的解决方案。业内有不少问题，最终看上去就是把磁盘换成SSD或者更加高性能的硬盘。而一体机几乎都是高性能硬盘来抗。我有时候在想现在国产数据库的硬件基本上都要内存128G起，甚至还有上T的内存。这是不是就知道国内开发就这个质量，不来点狠的硬件怕是要奔溃？

   我去年还参加了信通院主持的数据库一体机的标准制定，这个虽然是团体标准，至少也有了标准了。

   小结一下：数据库的优化是要一开始做对成本最低，一开始做对要求专业的人来设计（这个人可能不便宜，但是比起后期返工成本算低的）或者是一堆精通数据库的开发人员（这个价格应该不比那个总监成本低）。

   如果一开始就错了，要么返工，要么用硬件解决。如果没钱提升硬件。那么就要压榨一下开发还是从头再来设计，这就变成死循环了。