首页 | 新闻 | 交流 | 问吧 | 文档 | 手册 | 下载 | 博客

[SQL Server] 关于sql server的一些问题

作者:  时间: 2011-06-08

不要使用游标

  不知你是否知道每执行一次FETCH就等于执行一次SELECT命令?这意味着如果你的光标有10000条记录,它将执行10000SELECT

我曾经用T-SQL重写了一个基于光标的存储过程,那个表只有100,000条记录,原来的存储过程用了40分钟才执行完毕,而新的存储过程只用了10秒钟。在这里,我想你应该可以看到一个不称职的程序员究竟在干了什么!!!

我们可以写一个小程序来取得和处理数据并且更新数据库,这样做有时会更有效。记住:对于循环,T-SQL无能为力。

 不要使用SELECT *

这点不太容易做到,我太了解了,因为我自己就经常这样干。可是,如果在SELECT中指定你所需要的列,那将会带来以下的好处:

  1.  减少内存耗费和网络的带宽

  2. 你可以得到更安全的设计

  3. 给查询优化器机会从索引读取所有需要的列

使用事务

请使用事务,特别是当查询比较耗时。如果系统出现问题,这样做会救你一命的。一般有些经验的程序员都有体会-----你经常会碰到一些不可预料的情况会导致存储过程崩溃。

小心死锁

按照一定的次序来访问你的表。如果你先锁住表A,再锁住表B,那么在所有的存储过程中都要按照这个顺序来锁定它们。如果你(不经意的)某个存储过程中先锁定表B,再锁定表A,这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好,死锁是不太容易被发现的。

在程序编码时使用大数据量的数据库

程序员在开发中使用的测试数据库一般数据量都不大,可经常的是最终用户的数据量都很大。我们通常的做法是不对的,原因很简单:现在硬盘不是很贵,可为什么性能问题却要等到已经无可挽回的时候才被注意呢?

不要使用INSERT导入大批的数据

请不要这样做,除非那是必须的。使用UTS或者BCP,这样你可以一举而兼得灵活性和速度。

注意超时问题

查询数据库时,一般数据库的缺省都比较小,比如15秒或者30秒。而有些查询运行时间要比这长,特别是当数据库的数据量不断变大时。

在细节表中插入纪录时,不要在主表执行SELECT MAX(ID)

这是一个普遍的错误,当两个用户在同一时间插入数据时,这会导致错误。你可以使用SCOPE_IDENTITY,IDENT_CURRENT和@@IDENTITY。如果可能,不要使用@@IDENTITY,因为在有触发器的情况下,它会引起一些问题(详见这里的讨论)。

避免将列设为NULLable

如果可能的话,你应该避免将列设为NULLable。系统会为NULLable列的每一行分配一个额外的字节,查询时会带来更多的系统开销。另外,将列设为NULLable使编码变得复杂,因为每一次访问这些列时都必须先进行检查。

我并不是说NULLS是麻烦的根源,尽管有些人这样认为。我认为如果你的业务规则中允许“空数据”,那么,将列设为NULLable有时会发挥很好的作用

尽量不要使用TEXT数据类型

除非你使用TEXT处理一个很大的数据,否则不要使用它。因为它不易于查询,速度慢,用的不好还会浪费大量的空间。一般的,VARCHAR可以更好的处理你的数据。

尽量不要使用临时表

尽量不要使用临时表,除非你必须这样做。一般使用子查询可以代替临时表。使用临时表会带来系统开销,如果你是用COM+进行编程,它还会给你带来很大的麻烦,因为COM+使用数据库连接池而临时表却自始至终都存在。SQL Server提供了一些替代方案,比如Table数据类型。

学会分析查询

SQL Server查询分析器是你的好伙伴,通过它你可以了解查询和索引是如何影响性能的。

使用参照完整性

定义主健、唯一性约束和外键,这样做可以节约大量的时间。