快捷搜索:

关于SQL Server的若干注意事项

假如你正在认真一个基于SQL Server的项目,或者你刚刚打仗SQL Server,你都有可能要面临一些数据库机能的问题,这篇文章会为你供给一些有用的指示(此中大年夜多半也可以用于其它的DBMS)。

在这里,我不盘算先容应用SQL Server的秘诀,也不能供给一个包治百病的规划,我所做的是总结一些履历----关于若何形成一个好的设计。这些履历来自我以前几年中经受的教训,不停来,我看到许多同样的设计差错被一次又一次的重复。

你懂得你用的对象吗?

不要轻视这一点,这是我在这篇文章中讲述的最关键的一条。大概你也看到有很多的SQL Server法度榜样员没有掌握整个的T-SQL敕令和SQL Server供给的那些有用的对象。

“什么?我要挥霍一个月的光阴来进修那些我永世也不会用到的SQL敕令???”,你大概会这样说。对的,你不必要这样做。然则你应该用一个周末浏览所有的T-SQL敕令。在这里,你的义务是懂得,将来,当你设计一个查询时,你会记起来:“对了,这里有一个敕令可以完全实现我必要的功能”,于是,到MSDN查看这个敕令切实着实切语法。

不要应用游标

让我再重复一遍:不要应用游标。假如你想破坏全部系统的机能的话,它们倒是你最有效的首选法子。大年夜多半的初学者都应用游标,而没故意识到它们对机能造成的影响。它们占用内存,还用它们那些弗成思议的要领锁定表,别的,它们的确就像蜗牛。而最糟糕的是,它们可以使你的DBA所能做的统统机能优化即是没做。不知你是否知道每履行一次FETCH就即是履行一次SELECT敕令?这意味着假如你的游标有10000笔记录,它将履行10000次SELECT!假如你应用一组SELECT、UPDATE或者DELETE来完成响应的事情,那将有效率的多。

初学者一样平常觉得应用游标是一种对照认识和舒适的编程要领,可很不幸,这会导致糟糕的机能。显然,SQL的总体目的是你要实现什么,而不是如何实现。

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

我们可以写一个小法度榜样来取得和处置惩罚数据并且更新数据库,这样做无意偶尔会更有效。记着:对付轮回,T-SQL力所不及。

我再从新提醒一下:应用游标没有好处。除了DBA的事情外,我从来没有看到过应用游标可以有效的完成任何事情。

规范化你的数据表

为什么不规范化数据库?大年夜概有两个饰辞:出于机能的斟酌和纯挚由于怠惰。至于第二点,你迟早得为此付出价值。而关于机能的问题,你不必要优化根本就不慢的器械。我常常看到一些法度榜样员“反规范化”数据库,他们的来由是“原本的设计太慢了”,可结果却经常是他们让系统更慢了。DBMS被设计用来处置惩罚规范数据库的,是以,记着:按照规范化的要求设计数据库。

不要应用SELECT *

这点不太轻易做到,我太懂得了,由于我自己就常常这样干。可是,假如在SELECT中指定你所必要的列,那将会带来以下的好处:

1 削减内存消费和收集的带宽

2 你可以获得更安然的设计

3 给查询优化器时机从索引读取所有必要的列

懂得你将要对数据进行的操作

为你的数据库创建一个壮实的索引,那可是功德一件。可要做到这一点的确便是一门艺术。每当你为一个表添加一个索引,SELECT会更快了,可INSERT和DELETE却大年夜大年夜的变慢了,由于创建了掩护索引必要许多额外的事情。显然,这里问题的关键是:你要对这张表进行什么样的操作。这个问题不太好把握,分外是涉及DELETE和UPDATE时,由于这些语句常常在WHERE部分包孕SELECT敕令。

不要给“性别”列创建索引

首先,我们必须懂得索引是若何加速对表的造访的。你可以将索引理解为基于必然的标准上对表进行划分的一种要领。假如你给类似于“性别”这样的列创建了一个索引,你仅仅是将表划分为两部分:男和女。你在处置惩罚一个有1,000,000笔记录的表,这样的划分有什么意义?记着:掩护索引是对照费时的。当你设计索引时,请遵照这样的规则:根据列可能包孕不合内容的数目从多到少排列,比如:姓名+省份+性别。

应用事务

请应用事务,分外是当查询对照耗时。假如系统呈现问题,这样做会救你一命的。一样平常有些履历的法度榜样员都有体会-----你常常会碰着一些弗成预感的环境会导致存储历程崩溃。

小心逝世锁

按照必然的序次来造访你的表。假如你先锁住表A,再锁住表B,那么在所有的存储历程中都要按照这个顺序来锁定它们。假如你(不经意的)某个存储历程中先锁定表B,再锁定表A,这可能就会导致一个逝世锁。假如锁定顺序没有被预先具体的设计好,逝世锁是不太轻易被发明的。

不要打开大年夜的数据集

在CSDN技巧论坛中 :),一个常常被提出的问题是:我如何才能迅速的将100000笔记录添加到ComboBox中?这是纰谬的,你不能也不必要这样做。很简单,你的用户要浏览100000笔记录才能找到必要的记录,他必然会诅咒你的。在这里,你必要的是一个更好的UI,你必要为你的用户显示不跨越100或200笔记录。

不要应用办事器端游标

与办事器端游标比起来,客户端游标可以削减办事器和收集的系统开销,并且还削减锁准光阴。

应用参数查询

无意偶尔,我在CSDN技巧论坛看到类似这样的问题:“SELECT * FROM a WHERE a.id='A'B,由于单引号查询发生非常,我该怎么办?”,而普遍的回答是:用两个单引号代替单引号。这是差错的。这样治标不治本,由于你还会在其他一些字符上碰到这样的问题,更何况这样会导致严重的bug,除此以外,这样做还会使SQL Server的缓冲系统无法发挥应有的感化。应用参数查询, 釜底抽薪,这些问题一切不存在了。

在法度榜样编码时应用大年夜数据量的数据库

法度榜样员在开拓中应用的测试数据库一样平常数据量都不大年夜,可常常的是终极用户的数据量都很大年夜。我们平日的做法是纰谬的,缘故原由很简单:现在硬盘不是很贵,可为什么机能问题却要等到已经无可挽回的时刻才被留意呢?

不要应用INSERT导入大年夜批的数据

请不要这样做,除非那是必须的。应用UTS或者BCP,这样你可以一举而兼得机动性和速率。

留意超时问题

查询数据库时,一样平常数据库的缺省都对照小,比如15秒或者30秒。而有些查询运行光阴要比这长,分外是当数据库的数据量赓续变大年夜时。

不要轻忽同时改动同一记录的问题

无意偶尔候,两个用户会同时改动同一记录,这样,后一个改动者改动了前一个改动者的操作,某些更新就会损掉。处置惩罚这种环境不是很难:创建一个timestamp字段,在写入前反省它,假如容许,就合并改动,假如存在冲突,提示用户。

在细节表中插入记载时,不要在主表履行SELECT MAX(ID)

这是一个普遍的差错,当两个用户在同一光阴插入数据时,这会导致差错。你可以应用SCOPE_IDENTITY,IDENT_CURRENT和@@IDENTITY。假如可能,不要应用@@IDENTITY,由于在有触发器的环境下,它会引起一些问题(详见这里的评论争论)。

避免将列设为NULLable

假如可能的话,你应该避免将列设为NULLable。系统会为NULLable列的每一行分配一个额外的字节,查询时会带来更多的系统开销。别的,将列设为NULLable使编码变得繁杂,由于每一次造访这些列时都必须先辈行反省。

我并不是说NULLS是麻烦的根源,只管有些人这样觉得。我觉得假如你的营业规则中容许“空数据”,那么,将列设为NULLable无意偶尔会发挥很好的感化,然则,假如在类似下面的环境中应用NULLable,那的确便是自讨苦吃。

CustomerName1

CustomerAddress1

CustomerEmail1

CustomerName2

CustomerAddress2

CustomerEmail3

CustomerName1

CustomerAddress2

CustomerEmail3

假如呈现这种环境,你必要规范化你的表了。

只管即便不要应用TEXT数据类型

除非你应用TEXT处置惩罚一个很大年夜的数据,否则不要应用它。由于它不易于查询,速率慢,用的不好还会挥霍大年夜量的空间。一样平常的,VARCHAR可以更好的处置惩罚你的数据。

只管即便不要应用临时表

只管即便不要应用临时表,除非你必须这样做。一样平常应用子查询可以代替临时表。应用临时表会带来系统开销,假如你是用COM+进行编程,它还会给你带来很大年夜的麻烦,由于COM+应用数据库连接池而临时表却自始至终都存在。SQL Server供给了一些替代规划,比如Table数据类型。

学会阐发查询

SQL Server查询阐发器是你的好伙伴,经由过程它你可以懂得查询和索引是若何影响机能的。

应用参照完备性

定义主健、独一性约束和外键,这样做可以节约大年夜量的光阴。

您可能还会对下面的文章感兴趣: