前几天在一个群里看到大家讨论硬件。大佬说：现在谁还共享池总出问题？（早期因为资源不足，SQL烂一点的话会造成争用），现在随随便便都是1T的内存，哪里会有共享池问题？其他人也说自己是128G内存起。有人也说之前看Oracle要那么大内存，感觉太夸张，随便上百G，现在看国产。这么一笔下来，Oracle真节约。
对于以上问题，我第一个说我有时候还遇到共享池问题。因为我好多年没见过100G以上的机器了。早些年，我用64G的机器处理几十亿级别数据的时候也过来了。那时候是开发素质高，每个场景都是精心设计的。开发都是70后和80后。那时候入职面试还要考算法，数据库是必考。现在开发面试只有大厂才会考这些吧？因为一个无知的开发上去真的会把数据库搞死，然后直接导致系统故障，进而影响该公司的股价。我以前公司有个开发，我对他说你这样写不行。开始他不以为然，后来估计出去面试了一些好的公司，别人问的都不是那种假大空的问题，而是切切实实的基础问题。比如锁、并发等等。如果透过现象看本质，其实开发还是基于数据库开发，读取数据，其他的占比不大。所以他后来认识到了，开始转变，不再务虚，而是实实在在的看问题的本质。不过有这种认识的人太少了。
现在普遍一上来就是框架的，结果SQL奇差无比。在这种基因环境中，再配上较低的数据库，那就是经常伴随着这些问题。不同的数据库机制不同，但是内存大的在内存竞争上总是会缓解的。就像一家人很富有，一个人一套房子（不是每人一间而是一套），这种代沟也好，矛盾冲突也好，都减弱。另外一家10个人，在20平米房间，上个厕所都排队，能没矛盾吗？除非大家都是君子，素质很高。问题是这个前提条件不成立，因为本段开头写了都是奇差无比的。
我从离开公安行业以后依稀见过一些用物理机的公司，有跑DB2的，有跑Oracle的，也有跑MySQL的。基本来说稳如泰山，不是说他们开发写的多好，而是物理机的大内存，装载了更多数据，避免了磁盘读。而物理机的处理能力抵消了烂SQL带来的冲击。反观我也建立不少在虚拟机上运行Oracle和MySQL、PG的。这些就时不时的和你解闷一下。究其原因就是基础环境差配上烂代码。改造烂代码其实不容易，但是改造基础环境相对容易一些。找高水平的开发的成本远高于买好的硬件的成本。我想起我2017年看到的一款服务器150T的NVme，这个来存放公司的数据，（可能有的公司说放不下，他们公司数据多）我觉得放得下的公司远比放不下的公司多。我没有这个服务器配置的价格，我估计不会超过50万吧？找个好点的开发每年不止50万的成本吧？
另外一个错误的认知，我发现很难改变，就是非数据库领域的人已经被带偏了。就是虚拟化鼓吹的漂移。首先漂移是好的，但是去飘无状态的，比如tomcat等，这种甚至做到docker中我其实都没意见。但是有状态的数据库没必要，也不能飘。数据库遇到问题重启就好了，为了一致性重启会做redo和undo这不是漂移去解决的也解决不了。我还被经常问到，那坏了怎么办？一般来说不会坏。万一极端，这不是有高可用吗？Oracle RAC只有一个节点好就行。不用飘。 MySQL MGR只有一个节点好就行，不用飘。PG的集群没做过，但是主从切换一下就好，不用飘。redis的cluster，es mongo这些分片的半数只有半数以上或者，不用飘。见过hadoop飘吗？多副本就是干这个用的，没必要。而虚拟化上做数据库不会给一个很高的配置，因为不利于漂移。也不利于虚拟化自身。
所以当系统中发现几个tomcat的总资源大于数据库，或者说任意一个tomcat的资源等于数据库，其实就意味着这个系统中数据库的地位比较低下，那么日后出于数据库相关的问题就比较多。作为系统的中枢核心被轻视，后果比较严重。
数据库用物理机，最佳实践。高可用用数据库自身的，不推荐用虚拟化层来解决数据库的容灾，这样是为了小概率容灾，而限制了日常的使用。
仔细想想Oracle、阿里、腾讯、华为都出数据库一体机是有道理的。
