考试系统在进行压力測试时发现，并发量高之后出现了button无反应。试题答案不能写到数据库的问题，于是针对这些核心问题，进行了优化。

数据库方面：

    Select语句：Select * from TEB_VB_XZTRecord改为select 必须的列 form TEB_VB_XZTRecord。之前看的教学视频里就讲过最好别用*。因为查询了不必要的列，所以导致了低效率。

   insert优化：考试业务的原因。须要把查询出来的试题，一条条的插入到数据库中。优化前：循环+每次插入一条的insert语句。

优化后：insert 表名(字段名) select (字段名) from 表名 where questionID in(,,,,,,,)

    这样的优化在insert语句中用了select字句和inkeyword。相当于在数据库运行了查询之后。直接进行了查询。没有通过java项目的一次次的循环。之前想用一个insert+多个value的方法，发现这样的方式在mysql中行的通，但在oracle中行不通。

  

程序设计和算法优化：

    算法常常受个人思路的影响，比方对复用认识深刻，干过的事情就把成果保存下来，以后再用就高效了。

程序设计也是一样。

   

缓存同样数据

    考生的考试卷面，须要由考试信息、个人信息。考试卷面分值分布，试卷内容 四块内容组成。当中考试信息和卷面分值分布 对每一个考生都同样，因此将同样的信息进行缓存。就降低了大量的查询。而不是用一次查一次。

提前谋划，提前准备

    在大并发量时。能够提前干的事就提前干，就像请人在自己家吃饭，到了吃饭的点暂时准备饭菜，肯定手忙脚乱。提前准备出来到时候就悠闲了。

    对于考试系统的抽卷来说：考生考试时，每一个考生都随机从题库抽取一套试卷。这样的方法包括了大量的查询和一个循环，因此对性能要求较高。而且大并发量时导致了系统根本没反应。

    第一次优化：在考试前为考生抽好试卷，考生登录时仅仅需从答题记录表查询就可以。这样是把抽题的过程提前准备好了。

    第二次优化：考虑到第一次优化中扔须要大量的查询。这次优化的逻辑是 抽取固定的卷数，比方抽取50套，每套卷有一个卷号，考试前将50套卷载入到内存中。考生随机抽取到一个卷号，然后依据卷号从内存中拿试卷，这样仅仅要查询一次，然后其它考生都能够从内存中获取试卷，避免了大量的查询。

将事情分开干

    很忙的时候，把能够后推推的事情推后点。合理规划好资源和时间。答卷过程中，将客观题判分的环节移到了教师判分逻辑中，由于正确答案须要查询。所以在答题时会同一时候有大量的查询和更新操作。去掉了判分，答题时就仅仅有更新了。

   再有就是对String的优化，由于考试系统须要将试题显示在界面，因此须要在后台将试题拼好串，显示在前台，当时用了String。但String不是动态扩容的，仅仅会复制原来的String。加上新内容后新生产一个。因此存在着大量的存储浪费，改为了StringBuffer以后，对内存的要求小了非常多。