MIS系统性能问题根源及解决方案-灵活是性能之敌

       对于MIS系统的开发，很多人都会有这样的经历，先赶进度把系统开发出来收钱，后期再不断的进行性能调优，然而此时可调优的空间很小了。对于数据量较大的系统，最多维持系统稳定不宕机。开发在想在不修改代码的情况下，调整下数据库，加个索引，或是调整一下数据库参数，整改系统都飞起来了。领导在想怎么能找到一个NB的技术，一下子就能解决问题。如果能找到，请告诉下我，我认为不靠谱。我对公司系统的分析如下：

一、根源
     1.大量的SQL拼装

     2.大而全的视图

二、前阶段性能调优的反思

      对于维护性项目主要是对SQL进行调优。开发人员进行SQL调优优点在于熟悉业务，缺点调的不深入，常常只是加索引，要么备注写上无法调优，或者写上在测试环境上很快，无需调优。出现这个问题原因有三个：
       1.SQL调优技能不够；
       2.开发组不愿意对SQL有大的调整，不调优可以保障功能上没问题，只是慢一点，如果做了大的调整，说不定就会出问题。
       3.或许你认为性能是重要的事情，但站在开发的立场，进度是最重要的，宕机的问题他们会关注，系统慢的影响他们感受不到，只有现场实施能感受。
      有些开发的同事对代码的调优颇有心得，因为看过JDK的源代码，能够像JVM一样去思考。调优SQL需要理解Oracle内部原理，具备这种能力非一朝一夕之功，即使再多的培训，效果也不会明显。

三、如何分析出的根源
       很多人都知道性能是设计出来的，但都没指出设计到底出了问题，更谈不上措施。在表达观念之前我要铺垫一下，一条SQL的威力有多大，它可以让整个系统慢下来，它亦可以让整个系统变得不可用。从我现在获得的信息来看，公司的性能是不可控的，

       1. 造成不稳定的原因是系统中大量的SQL拼装。如查询功能，只要是功能模块表单有的字段都加上去，后续用户的字段都好不犹豫的加上去。只有少数的查询条件有索引，当拼装出不走索引的，对于数量少的模块就出现时快时慢，对于数据量大的模块就出现整个系统慢下来，极端一点系统不可用。我们只能祈祷上帝，期望用户不要去选择那些执行效率差的条件。

       2. 大而全的视图。在写代码的时候每个模块都有util和helper包，把此模块通用的功能写到里面，这对写代码是一种很好的经验。开发人员好不犹豫的将此经验用到写SQL上，于是每个模块都出现了一个大而全的视图，以求达到通用。对数据库的监控，结果是发现耗性能的SQL排在前几位的就是用到的这些大视图。

四、调整措施
       1.  解决SQL拼装的问题。在设计阶段DBA要强势进入，从性能角度对表进行规划，分表、分区、索引进行战略性规划。DBA要与分析人员进行PK，对性能有较大影响的功能从需求和性能上进行平衡。例如查询功能，有些条件对性能危害大的就不能加。这个时候会出一个问题，分析人员会说这个是用户要求的，DBA对此事会无解。所以DBA也要学习业务，要有自己的判断，DBA已不是传统定义的DBA，更像一位架构师。

       2.  解决大视图的问题。在工程中查找到使用大视图的业务，分析是否一定要使用，如不需要的进行SQL重构，或是进行数据归档。

     总结：SQL拼装和大视图有一个共同点，就是灵活，让代码写起来简单，从代码的角度逻辑清晰。恰恰是这种灵活使系统性能不可控，灵活是性能之敌。