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

数据库方面：

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

   insert优化：考试业务的原因，需要把查询出来的试题，一条条的插入到数据库中。优化前：循环+每次插入一条的insert语句。优化后：insert 表名(字段名) select (字段名) from 表名 where questionID in(,,,,,,,)

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

程序设计和算法优化：

    算法经常受个人思路的影响，比如对复用认识深刻，干过的事情就把成果保存下来，以后再用就高效了。程序设计也是一样。

缓存相同数据

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

提前谋划，提前准备

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

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

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

    第二次优化：考虑到第一次优化中扔需要大量的查询，这次优化的逻辑是 抽取固定的卷数，比如抽取50套，每套卷有一个卷号，考试前将50套卷加载到内存中，考生随机抽取到一个卷号，然后根据卷号从内存中拿试卷，这样只要查询一次，然后其他考生都可以从内存中获取试卷，避免了大量的查询。

将事情分开干

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

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