2、根据查询条件,建立索引,优化索引、优化访问方式,限制结果集的数据量。
3、扩大服务器的内存
4、增加服务器CPU个数
5、对于大的数据库不要设置数据库自动增长,它会降低服务器的性能
6、在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据,浪费了服务器的I/O资源,加重了网络的负担降低性能。如果表很大,在表扫描的期间将表锁住,禁止其他的联接访问表,后果严重。
7、查询时不要返回不需要的行、列
8、用select
top
100
/
10
Percent
来限制用户返回的行数或者SET
ROWCOUNT来限制 *** 作的行
9、在IN后面值的列表中,将出现最频繁的值放在最前面,出现得最少的放在最后面,减少判断的次数
10、一般在GROUP
BY
个HAVING字句之前就能剔除多余的行,所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优:
select的Where字句选择所有合适的行,Group
By用来分组个统计行,Having字句用来剔除多余的分组。这样Group
By
个Having的开销小,查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group
BY的目的不包括计算,只是分组,那么用Distinct更快
11、一次更新多条记录比分多次更新每次一条快,就是说批处理好.
在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ,在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
尽可能的避免更新 clustered 索引数据列,因为 clustered 索引数据列的顺序就是表记录的物理存储顺序,一旦该列值改变将导致整个表记录的顺序的调整,会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列,那么需要考虑是否应将该索引建为 clustered 索引
临时表并不是不可使用,适当地使用它们可以使某些例程更有效,例如,当需要重复引用大型表或常用表中的某个数据集时。但是,对于一次性事件,最好使用导出表。
应尽量避免在where子句中对字段进行函数 *** 作,这将导致引擎放弃使用索引而进行全表扫描。
如果在 where 子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)