昨天谈到优化的话题，不少朋友留言谈了他们对优化的看法。很多人认为能用硬件解决问题的那就用硬件去解决，还有些朋友认为解决好应用的问题，就不存在什么优化的问题了。实际上处于每个人自己的环境中，他自然而然会根据手边的资源以及自己对系统优化的认知来完成优化方案的选择。个体差异很大，因此优化方案的选择也是个性化的，不能说你的经验对别人就一定有效。

升级硬件能解决问题，并且升级硬件成本不高的情况下，也许升级硬件是最好的选择。十年前一个客户让我去优化一下他们的ERP系统，当时他的预算是20万以内。我看了一下，数据库不大，也就200GB，但是因为二开模块的水平有限，数据架构设计也不是很合理，导致IO负载很高，而他们的RAC系统只用了一台20万左右的低端存储，IO能力是明显不足的。如果要想把优化做好，20万以内的预算是不太够用的。于是我帮他们把RAC拆了，买了几块SSD盘，搭建了一套DATAGUARD系统，用本地的SSD盘来跑数据库。改造硬件外加我们的实施费总共花了十万出头，效果很好。

2015年我去澳洲的时候拜访了一个银行工作的朋友，他在90年代去澳洲之前和我学了几个月的Oracle，出国后幸运地在一家不小的银行里找到了一个DBA的职位，并逐步提升到了基础设施的总监。他们以前用AS/400小型机，系统优化是一个大事，他们把系统优化外包给IBM，每年花费巨大。后来在他的建议下，数据库服务器换成了ORACLE EXADATA，系统优化基本上不需要了。过几年买一套新的EXADATA，利用ADG技术滚动升级上去就可以了。他们算了笔帐，采取新的技术架构后比以前买IBM的优化服务省了不少钱。而且因为EXADATA强大的能力，他们的新业务上线也变得大胆多了，对银行业务的支撑能力也大大提升，他也因此深得董事会的信任。

不过也不是所有的情况都适合硬件升级，有一次给一个浙江的客户做优化，他们的系统用的是IBM 740小型机，刚刚上线不到一年就出现了严重的性能问题，上级部门要求统计数据的时候经常因为应用超时而迟迟无法上交，经常被上级领导在大会小会上点名批评。硬件采购与升级都需要比较长时间的计划和审批，而且才上线一年的系统就要求升级也不大现实，因此优化工作就迫在眉睫了。

刚开始他们还寄希望于应用优化，不过我们分析了一下应用后发现因为应用架构的设计问题，没有设计分级汇总功能，而且上级要求的报表都是即席报表，是通过一个报表工具生成出来的SQL，统计口径和统计条件十分复杂，统计时间段可能会追溯数年。基于此现状，全表扫描是统计操作经常要做的，优化SQL难度较大。而不幸的是，当时设计硬件的 时候为了省钱，存储选择了很低端的存储，只有8GB的缓冲。在规划优化方案的时候，我们重点放在了IO性能的提升和减少IO上。在数据库层面上，我们把表分区的粒度切得更细，并设计了KEEP POOL缓冲常见表的数据(此项设计减少了一半物理读IO)。在存储性能提升方面，我们让用户把库存的几块磁盘加入进去，建立了一个新的磁盘组，把部分热数据迁移到了新的盘组，同时根据系统的读写特点(写是分散写，读是集中读，读占90%，写占10%)调整了读写缓冲的比例，让70%的缓冲作为读缓冲，30%的缓冲作为写缓冲(调整前80%写缓冲，20%读缓冲)。经过调整后，高峰期平均IO延时从 100多毫秒降低到15毫秒左右，报表数据出不来的问题彻底解决了。

系统优化工作可能离某些读者比较远，因此他们也不大理解这项工作的必要性。实际上系统优化工作如果只是流于表面，确实意义不大，哪怕你一次性优化了几百条SQL，当时把系统性能提高了很多，不过因为系统中的一些基础性的硬伤存在，那么过一阵子，软件做几次升级，系统又不行了。系统优化是要将系统中存在的各种堵点都疏通干净，让底层存在的问题尽可能消除缺陷，从而更好地保障系统运行。

最后的这个例子也是十年前的了，当时一个用户的ERP系统到了月底结算时就特别慢，表现在IO性能级差。而系统的存储系统是一台高端的存储，能来不差，连载这台存储上的其他数据库IO性能都很好。只有这套数据库，IO吞吐量达到400M的时候IO延时就几十毫秒了。开始用户把HBA卡扩充到了8GB，但是没有什么效果。最后我们一级级排查，终于发现这套系统连接的边缘SAN交换机太老了，端口是2GB的，双卡400M就到极限了。于是我们把小型机上的4个HBA卡全连上，问题就解决了。