首先跟大家讲一下我们现在这个项目的结构模式：
1、服务端采用WCF编写的，主要负责数据的读写操作
2、客户端传入相应的语句与参数来从服务器获取数据
遇到的问题：
每次打开UI界面的时候速度都很慢，每次都要等上好几秒钟，哪怕查询结果只有十多条数据，总是让人觉得这个系统是不是挂掉了，后来加了一个假的进度条来显示加载数据的过程，用户体验好了一些，但还是要等好久
有没有人能提供一些优化的思路呢？
我下面把我自已的一些思路写下来，大家帮我看看，帮我提提建议，或者有更好的优化方法那更好：
1、首先把所有用户都共同的系统基础数据保存到本地，每次登陆系统的时候自动更新本地的基础数据（如分组类型数据、职位、部门、区域），这样每次打开界面或查询数据的时候就不需要从数据器获取了，直接从本地读取就可以了；
2、其次，把系统的所有查询语句改成用存储过程，减少上传服务器的数据量，只上传存储过程名称和相关的参数值就可以了
3、再就是优化数据库的索引
4、最后压缩需要传输的数据，以减少传输返回的数据量
希望这样来提搞系统的性能，不知道能提高多大的性能，你们认为如何呢，有没有其它更好的办法呢？
1. 缓存的意思，许多人都片面理解为在客户端保存一些数据。这其实谁都会做。真正关键的技术是看你会不会控制缓存依赖，即保证缓存的数据不是脏数据，当后台数据改变的时候缓存中的数据就有一部分（至少包括所有脏数据）被自动清除了。所以缓存依赖技术，才是缓存技术的本质。
2. 你的WCF是用来传送sql语句？这个我实在是无言了。这不是我所知道的业务服务的理念。
3. 写查询sql的时候，比如你写到“where file1=...”或者“inner join ... on a.xxx=b.yyy....”这类代码的时候，就知道查询条件有没有索引可用了。这是一个基本的编程素质。我一般来说不把它当作什么技术，而是当作基本常识。
4. 别忘了，执行压缩本身也是很占时间的。对于那些古老的、大页面的传送，也许压缩可行。但是对于小而短促的通讯，压缩了可能反而字节数更大。如果盲目压缩，还不如先看看是不是自己的服务功能设计得过于臃肿了。
我建议你们将WCF先放在一边，让许多服务也可以使用简单的比如http、tcp方式通讯，来对比一下速度。同时假设你们的服务器不是asp.net而是windows service，那么可能再也不会遇到那种明明没有进行查询和计算却“等上好几秒钟”的情况。特别是对于大数据量的服务，要提供更简单的通讯方式。where file1=.. --> where field=..