第一：编写限制搜索范围的查询语句。
　　众所周知，在数据库查询的时候返回记录的多少直接关系到查询的效率。所以，在客户端通过一定的条件语句，限制搜索的范围，往往可以大幅度的提高查询的效率。
　　如用户在客户端查询数据库的时候，在查询语句中，加入TOP语句，让其显示前面的50条或者100条记录。因为根据经验，用户在查询数据的时候，60%左右要查看的都是靠前面的记录。特别是在一些历史交易信息表中，如在ERP系统的库存交易表中，就可以只显示前面几百条的记录，而不需要显示所有的记录。当用户觉得记录不够时，可以按“全部”，然后客户端再去服务器查询所有的结果。这种设计的话，就可以非常有效的提高数据库的查询性能。
　　如可以在在客户端设置默认的条件语句。如在ERP系统中，有个采购定单的表单;在后台数据库中，就对应着采购定单这么一张表。默认在查询采购定单的时候，查询到的是未结帐的采购定单。如此的话，即使用户在查询采购单时，没有输入采购定单号或者定单日期等限制条件，客户端在向服务器递交查询语句的时候，会默认把限制条件语句加入进去。如此，对于提高数据库首次查询的效率是非常有帮助的。
　　当然，无论是利用TOP语句，还是利用Where语句设置默认的限制条件，都不是随便设置的。这往往需要根据客户的使用习惯与表单的性质，来进行确定。如对于客户信息表，其客户本来数量也不多，所以，就没有必要设置限制搜索范围的查询语句。但是对于库存交易明细表，一个月下来，就有可能有成千上完条记录。如此海量的数据，若不设置限制条件的话，则查询起来，用户等待的时间会比较长。所以，针对这种情况，我们默认可以其只显示前面500条记录或者只显示最近30天之内的交易信息。
　　总之，在客户端适当的加入限制搜索范围的查询语句，是在客户端提高数据库服务器性能的一个首选的方法。
　　第二：尽量不要采用复杂的存储过程。
　　SQL Server数据库虽然提供了很强的存储过程功能，但是，在前台应用程序设计的时候，最好不要频繁的去调用数据库的存储过程。这主要是因为存储过程虽然方便，但是其执行速度没有普通的应用程序，如C语言那么快。
　　而从功能上看，很多存储过程可以完成的功能，前台应用程序完全可以实现。如在一些进销存管理系统中，往往需要把小写金额转换成大写金额，在采购定单上打印出来。这个功能即可以通过数据库的存储过程实现，也可以通过前台的应用程序实现。但是，根据笔者的观察，发现数据库的存储功能的性能不是很理想。若存储过程稍微比较复杂的话，如参数比较多时，客户端的响应时间就会比较慢。相反，如果不是在数据库后台实现这个功能，而是直接在前台利用应用程序实现的话，则其速度就会快许多。
　　另外，若在后台数据库中建立存储过程的话，会增加服务器的工作量。设想一下，现在采购部门有十个员工，若在一个时段内，都在维护采购定单的话，则就要同时调用这个存储过程，那么对于服务器的资源就会“争用”。相反，若在客户端实现这个功能的话，因为其都是在客户端上执行，所以服务器资源大家就不用你争我夺了。
　　所以，笔者在数据库设计的时候，很少采用存储过程。能够利用客户端应用程序实现的，就采用前台应用程序实现。真的要采用存储过程的话，也要采用那些减少争用和增加并发性的存储过程。
　　　第三：在客户端采用高速缓存提高服务器性能。
　　我们都知道，数据库在设计的时候，也用到了缓存。缓存是操作系统内存中间的一个模块。因为从内存中读取数据要比在硬盘中读取数据要快的多，所以，在数据库中通过把拥护查询过的数据记入到缓存中去，从而可以服务器的性能。
　　现在有些程序开发人员更进一步。在客户端应用程序上，也可以假如缓存。客户端的缓存跟服务器端的缓存有异曲同工之妙。当某个用户查询了采购定单价格变更记录的时候，即使用户关掉了表，则其查询的数据仍然会在一定时间内保存在客户端的缓存中。当用户下次需要这方面数据的时候，则客户端就不会直接从数据库服务器从查询，而是先从客户端的缓存中找起。只有客户端应用软件的缓存中没有这方面信息的时候，才会把语句反馈给服务器，从服务器中提取数据。通过这种方式，就可以在客户端上分担服务器的压力，改善SQL Server数据库的性能。
　　不过，若在客户端设置了高速缓存的话，则最好在应用软件上，增加清除高速缓存的按纽。因为在默写情况下，我们可能想要知道即使更改的结果，而不是最后一个看到。如我们在服务器上，改变了某个金额。但是，由于在客户端上刚查询过这方面的数据，数据内容还在缓存中。则仍然显示的是哪个未改过之前的情况。此时，就需要通过“清除高速缓存”的方法来及时的看到改变后的内容。
    第四：在前台实现表的完整性约束。
　　如果在后台数据库实现表的完整性约束，如某个字段不能为空的话，则需要经过很多个步骤。如客户端程序先把结果传递给表;然后在存储的时候，发现某个字段为空，不符合表的完整性约束的要求;数据库拒绝保存这条记录，并返回错误信息;数据库服务器把这个结果传递给客户端。很显然，这种处理机制比较麻烦。那么有没有什么简单的解决方法呢?
　　其实，我们若通过前台的客户端应用程序来实现表的完整性约束，可能对数据库的性能更加的有利。如在前台的客户端界面中，有某个字段不能为空。此时，我们就可以在前台应用程序开发的时候，加一限制，当这个字段为空的时候，不能保存。在前台客户端都不能够保存的数据，则当然不会传递给后台的数据库服务器。通过这种在前台实现表的完整性约束，就可以减少这个处理的过程。可以保障传递给后台数据库的内容都是符合完整性约束的。
　　另外，就拿默认值来说，也是在客户端应用程序中实现来的便捷。如笔者在数据库开发的时候，需要有一个记录创建与更新日期。这两个字段的话，就可以在为其创建默认日期。现在的问题就是是在前台客户端程序实现呢，还是在后台的数据库中实现限制呢?笔者比较倾向与前台。因为在前台，客户端直接会把当前的默认值传递给服务器，服务器直接保存即可。而不用触发服务器的默认日期的存储过程。
　　总之，笔者认为，我们在考虑改善数据库性能的时候，需要客户端与服务器端一起努力。或许通过这种方式，可以给我们一些意外的收获。使用过后，大家可能都会由衷的发表感叹，认同笔者的做法。