“系统优化从需求分析开始”,这是老白在十多年前《Oracle通讯》上发表的一篇关于系统优化的文章《应用系统生命周期与Oracle数据库优化》一文中提出的口号。
需求开发分为客户需求获取、需求分析两个阶段，最终产品为软件需求规格书（SRS）。在传统的概念中，这个需求开发和系统优化是风马牛不相及的事情，而这个阶段往往是对系统性能优化最为关键的阶段。在这个阶段主要考虑的是软件的功能需求，而这些需求中，可能存在一些对系统性能影响极大的需求。操作习惯、界面风格、统计方法等都会影响数据库的性能。
以下是一个真实的案例，某个系统在显示主菜单的时候，需要显示一些复杂的实时统计分析结果，而这个统计分析结果只有很少数的人会真正关心，由于这个系统有几百个用户在使用，而主菜单是进入每个模块的必经之路，因此系统运行一段时间后，就出现了CPU方面的瓶颈。为了解决这个问题，DBA想尽了一切方法对SQL进行优化，但是收效甚微。最后我分析了这个问题后提出了一个方案，重新修改了主菜单的界面，缺省情况下不显示实时统计结果，而只是提供一个显示实时统计结果的链接。而对于需要每次显示主菜单都显示实时统计结果的用户，只需要在自己的PROFILE中设置该选项就可以了。主菜单修改后，使用实时统计的用户只有1％左右，CPU的瓶颈问题也就迎刃而解了。
上述这种优化如果在需求分析阶段就能够完成，那么可以避免很多问题，而事实上类似的故事在不停的重演。究其原因，主要是参与需求开发的人员往往是业务人员和软件开发人员，这些人员缺乏系统优化的基本知识和经验，无法从需求中发现隐含的性能问题。因此在需求开发阶段，专业的运维与优化人员的介入是十分重要的，具有系统优化经验和软件开发经验的DBA可以在这个阶段就及时发现对于性能影响较大的需求，并且寻求解决方案，引导客户采用比较优化的操作模式。
有可能有些朋友觉得老白举的这个例子过于生僻，实际上，在我们信息系统建设中有很多在需求阶段需要考虑而大家往往忽略的问题，很多问题实际上或多或少的对每一个系统都有巨大的影响。就以历史数据查询为例吧，因为这涉及到查询的性能、系统的资源开销、历史数据归档等多个问题，往往是我们运维人员十分关注的问题。运维人员一直在说业务部门的需求不合理，查询的时间窗口太大了，导致了他们运维增加了额外的压力。而业务部门也一直指责因为历史数据查询的限制，导致了客户的满意度下降。金融行业是最早发现历史数据查询对在线系统的巨大影响的，所以早期的银行都把交易查询分为当天交易和历史交易。实际上在绝大多数银行的核心账务系统中，当天交易数据表中只有当天的数据。我想大多数人都在银行柜面或者网银上查过交易明细。现在的银行系统已经比较人性化了，不需要把当天交易与历史交易分开查询，不过在查询时间区间上还是有限制的，很多银行设置了每次查询区间不超过3个月，查询的历史数据不超过1年这样的限制。这种业务上的限制有效的保证了查询数据时SQL语句的效率，限制了SQL语句的成本开销，同时也为数据归档等工作提供了有力的支撑。如果用户要查询一年以前的数据，那么也不是不能查，你必须带上证件到柜面去查。这样也把一些可有可无的查询一年前数据的需求抑制住了。
大家是不是觉得金融行业的历史数据查询的策略做的十分好了？实际上这种业务设计还有很好的提升余地。实际上，目前银行对于超过3个月的数据查询是一刀切的不允许，用户如果要查超过3个月的数据，不好意思，您分两次查询。如果系统设计的更为合理的话，应该是后台自动把查询切分成多个3个月的查询，异步执行，最后输出结果，甚至设定此类查询可以做但是是非实时的，需要等待几十秒或者一分钟。对于超过一年的交易查询，目前的做法虽然对银行业务有利，但是对用户来说还是不够方便。可以将业务模式改为用户提出查询申请，在1个工作日内，经过银行审核将查询结果发送到客户的邮箱里。这样这类查询可以安排在业务比较空闲的时段做批处理查询，既避免了此类查询影响实时交易，又可以最大限度的方便客户。通过自动化的审核手段，还可以过滤一些不合理的查询请求，从而避免此类作业对系统造成过大影响。
