[分享]谈谈速度问题**

alang

“出现了问题，分析问题原因，找到解决方法”这是我们通常的思路，但是有些问题，比如速度问题，等到问题出现往往已经晚了，这时候在解决有很大的投入，甚至重做来解决。
速度问题最好是在最初就始终关注，最大限度的减少速度问题的出现，而不是在问题出现之后再想办法解决。

在需求调研阶段，就要对每一种业务可能产生的数据量有一个数量级的概念，对于用户量形成概念，对于使用频度、并发访问等形成概念，这些都会大大的影响最终应用的执行速度的。
需求阶段要得到表单，更要得到报表或者客户的常用的查询方式，在数据表结构设计时候就要考虑这些问题，通过冗余字段、建立索引等手段来数据的查询效率。
如果表中存储的数据量很大，那么在对这些数据访问的数据集设计时候就要小心了，如何减少返回的数据量是要在开发中随时考虑的问题。
对于使用频繁的功能，要设计易用友好的界面，让用户方便操作，提高用户使用中的速度。
根据用户量、并发量等综合考虑采用什么样的数据库和采用什么样的服务器硬件。
需求调研阶段还有一个重要的工作就是了解客户使用环境的信息，例如客户机一般采用什么配置，客户端到服务器一般采用什么样的网络连接等等。对于局域网的应用，速度问题就可以稍微放松一些，但是对于互联网的应用，就要考虑如何减少网络交互次数和网络交互的数据量，来尽量减少网络对速度的影响了。

alang

上面主要谈了需求阶段和设计阶段需要注意的事情，下面谈谈实现阶段。
在实现阶段，对于普通的表一般不需要特殊的考虑，就用最简单的思路就就可以了，但是如果涉及到数据量大的表就要注意了。
加深对数据库SQL语句的了解，达到相同的功能，可以有多种SQL语句的写法，不同的写法性能差距非常大，因此要针对不同的数据库采用不同的SQL语句来实现。更进一步的，有专门的工具，你给出一条SQL语句，他可以给出最优化的SQL语句来。
减少从数据表中取的数据量，从业务需求的角度出发，尽量过滤掉不需要的数据，其实上万条数据去到客户端，也没有办法一条一条的浏览，这种情况可以给出符合条件的记录数，以及一些其他的统计情况，采用分组取数据的方式来一次只取很少的数据到客户端浏览。
除了服务器取数据的瓶颈之外，还要注意，有些速度问题的瓶颈是在客户端上，比如：循环滚动数据集时候没有DisableControls等，要加深对开发工具本身以及对各种控件的理解。

alang

速度问题还有一个关键阶段，往往会被忽略掉，在完成应用以后，一定要进行测试，尤其是要在表中知道出大量的数据，测试在大数据量下，功能速度是否有问题，千万不要等到客户发现慢了才来解决。等客户发现问题时候，这时候往往发现原来的表结构不太合理，需要调整表结构，但是客户已经有了大量的数据，这时候再改会有很多的工作需要做。
需要修改表结构
需要按照新的表结构来调整应用
需要把旧的大量数据转到新的表中
需要特殊考虑数据转换中还没有完成的业务的数据
... ...