64-买了一体机，就可以高枕无忧了吗？(重发)

为什么说到一体机的话题？因为有朋友在我的前一篇培训招生公众号文章下面留言：“一体机时代，性能优化已经没那么重要了”。看了一下，这位朋友关注我的公众号有一年多了，可能是最近才用上一体机，自我感觉良好。

一体机真的有那么神奇吗？我们来看一个活生生的案例：

某保险业客户，新购一台半配oracle Exadata（原厂一体机，一体机中的战斗机，大部分客户买1/4配，半配已经是很高的配置了），做完系统迁移后，满心期待原有系统跑不出结果的业务能够正常使用，然而事与愿违，SQL执行了8小时，还在欢快的跑着，距离出结果的时间还是遥遥无期，有图有真相：

客户比较生气，花了几百万买的战斗机，开起来怎么还像拖拉机？分析后发现问题非常清晰：开发人员写的SQL是低效的，再好的硬件无法发挥作用；DBA关闭了统计信息收集，再多的资源也会被耗光。SQL写法：

这些业务SQL完全无法使用Exadata一体机的特性，而且统计信息不准也是致命伤，8小时跑不出来也是合情合理的。

普通客户对一体机了解不够情有可原，但是一些号称专业服务一体机的专业人士，有的还是Oracle的ACE，出版了几本书的"高级"专家，写出来的性能诊断分析文章居然也是存在低级失误，实属不该：

说明：关于并行的写法和并行进程的计算都是错误的

现在很多系统的主要瓶颈是存储压力大，有些系统已经把存储换成了全闪存，存储的性能基本上可以匹配普通一体机的性能（oracle原厂一体机exadata特有的smart scan技术，在某些情况下还能通过软技术提升一些存储性能，在OLAP系统表现比普通一体机更为优秀，这也是Exadata卖的贵的主要原因），磁盘技术的革命临时把这些系统暂时解救了，但是等再过一段时间，随着业务量和数据量的增长，全闪存也顶不住的时候，是不是只能搞分库分表了？

其实很多系统都有一定的优化空间，优化后可以大大降低CPU、存储和内存的消耗，只是开发人员和DBA都看不到。很多时候开发人员更是系统上线后就不再关注，后面事情全权交给DBA处理，殊不知系统的性能问题，大部分都是开发留下的坑。很多DBA的优化水平，也就只能创建一些简单索引；改几个参数（可能还是画蛇添足）；执行计划变差，用sql profile绑定一下（没有好的执行计划怎么办？）；再就是使用sql tuning advisor，让数据库自己做个简单优化。DBA如果找不出根因反馈给开发，只能自己默默背锅。

更换一体机解决的问题主要是压力在存储的系统：OLTP系统IOPS不够，OLAP系统吞吐量不够，这些问题都能得到明显的改善。

但这只是性能不佳的一个方面，更多的还是在开发和维护，首先是架构设计 ：

应用设计的时候根本没有考虑RAC的特性，造成应用在多个节点的RAC上执行效率还没有单机性能高。国内某保险业巨头，技术也是业界排头兵，应用系统基本上是不用RAC的，用的是老式的HA(主备式，主用出问题再切换到备用); 还有很多移动公司，多节点RAC，业务只部署在其中一个节点，其它节点闲着，浪费了宝贵的硬件资源。

优化需要解决的事情还有很多，诸如连接风暴、并发设计、分区设计、sequence序列争用、行锁等待、游标泄漏、隐式类型转换、不合理参数设置、统计信息不及时收集、复杂SQL执行计划选择错误（没有好的执行计划）、优化器bug、优化器局限性、不使用绑定变量、低效SQL写法、索引争用、缺少关键索引、使用低效索引等等等等，这些问题是你买个一体机就能解决的吗？

结论：

系统有压力才会选择一体机，用了一体机，就要发挥出一体机的特长，不发现和解决上面列举的问题，系统配置再高也只是扬汤止沸而已。只有优化，才能达到釜底抽薪的效果。