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