SQL Server 设计规则

心心失意

SQL Server 设计规则
　　如果你正在负责一个基于SQL Server的项目，或者你刚刚接触SQL Server，你都有可能要面临一些数据库性能的问题，这篇文章会为你提供一些有用的指导（其中大多数也可以用于其它的DBMS）。
一、了解你用的工具
　　不要轻视这一点，这是我在这篇文章中讲述的最关键的一条。也许你也看到有很多的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，这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好，死锁是不太容易被发现的。
九、不要打开大的数据集
　　一个经常被提出的问题是：我怎样才能迅速的将100000条记录添加到ComboBox中？这是不对的，你不能也不需要这样做。很简单，你的用户要浏览100000条记录才能找到需要的记录，他一定会诅咒你的。在这里，你需要的是一个更好的UI，你需要为你的用户显示不超过100或200条记录。
十、不要使用服务器端游标
　　与服务器端游标比起来，客户端游标可以减少服务器和网络的系统开销，并且还减少锁定时间。
十一、使用参数查询
　　有时，我在CSDN技术论坛看到类似这样的问题：“SELECT * FROM a WHERE a.id='A'B，因为单引号查询发生异常，我该怎么办？”，而普遍的回答是：用两个单引号代替单引号。这是错误的。这样治标不治本，因为你还会在其他一些字符上遇到这样的问题，更何况这样会导致严重的bug，除此以外，这样做还会使SQLServer的缓冲系统无法发挥应有的作用。使用参数查询， 釜底抽薪，这些问题统统不存在了。
十二、在程序编码时使用大数据量的数据库
　　程序员在开发中使用的测试数据库一般数据量都不大，可经常的是最终用户的数据量都很大。我们通常的做法是不对的，原因很简单：现在硬盘不是很贵，可为什么性能问题却要等到已经无可挽回的时候才被注意呢？
十三、不要使用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查询分析器是你的好伙伴，通过它你可以了解查询和索引是如何影响性能的。
二十一、使用参照完整性
　　定义主健、唯一性约束和外键，这样做可以节约大量的时间。


SQLServer DO's and DON'Ts
　　
　　So, you are nowthe leader of a SQL Server based project and this is your first one, perhapsmigrating from Access. Or maybe you have performance problems with your SQLServer and don't know what to do next. Or maybe you simply want to know of somedesign guidelinesfor solutions using SQL Server and designing Database AccessLayers (DAL): this article is for you.
　　
　　Even if you arenot using SQL Server, most of these design guidelines apply to other DBMS, too:Sybase is a very similar environment for the programmer, and Oracle designs maybenefit from this too. I won't show here how to use specific T-SQL tricks, norwon'tgive you miracle solutions for your SQL Server problem. This is by nomeans a complete, closed issue. What I intend to do is give you some advicesfor a sound design, with lessons learned through the last years of my life,seeing the same design errors beingdone again and again.
DO know your tools.
　　
　　Please, don'tunderestimate this tip. This is the best of all of those you'll see in thisarticle. You'd be surprised of how many SQL Server programmers don't even knowall T-SQL commands and all of those effective tools SQL Server has.
　　
　　"What? Ineed to spend a month learning all those SQL commands I'll never use???"you might say. No, you don't need to. But spend a weekend at MSDN and browsethrough all T-SQL commands: the mission here is to learn a lot of what can andwhat can't be done.And, in the future, when designing a query, you'll remember"Hey, there's this command that does exactly what I need", and thenyou'll refer again to MSDN to see its exact syntax.
　　
　　In this articleI'll assume that you already know the T-SQL syntax or can find about it onMSDN.
DON'T use cursors
　　
　　Let me say itagain: DON'T use cursors. They should be your preferred way of killing theperformance of an entire system. Most beginners use cursors and don't realizethe performance hit they have. They use memory; they lock tables in weird ways,and they areslow. Worst of all, they defeat most of the performanceoptimization your DBA can do. Did you know that every FETCH being executed hasabout the same performance of executing a SELECT? This means that if yourcursor has 10,000 records, it will execute about 10,000SELECTs! If you can dothis in a couple of SELECT, UPDATE or DELETE, it will be much faster.
　　
　　Beginner SQLprogrammers find in cursors a comfortable and familiar way of coding. Well,unfortunately this lead to bad performance. The whole purpose of SQL isspecifying what you want, not how it should be done.
　　
　　I've oncerewritten a cursor-based stored procedure and substituted some code for a pairof traditional SQL queries. The table had only 100,000 records and the storedprocedure used to take 40 minutes to process. You should see the face of thepoor programmerwhen the new stored procedure took 10 seconds to run!
　　
　　Sometimes it'seven faster to create a small application that gets all the data, proccess itand update the server. T-SQL was not done with loop performance in mind.
　　
　　If you arereading this article, I need to mention: there is no good use for cursors; Ihave never seen cursors being well used, except for DBA work. And good DBAs,most of the time, know what they are doing. But, if you are reading this, youare not a DBA,right?
DO normalize your tables
　　
　　There are twocommon excuses for not normalizing databases: performance and pure laziness.You'll pay for the second one sooner or later; and, about performance, don'toptimize what's not slow. Often I see programmers de-normalizing databases because"this willbe slow". And, more frequent than the inverse, theresulting design is slower. DBMSs were designed to be used with normalizeddatabases, so design with normalization in mind.
DON'T SELECT *
　　
　　This is hard toget used, I know. And I confess: often I use it; but try to specify only thecolumns you'll need. This will:
　　
　　1. Reduce memory consumption and networkbandwidth
　　2. Ease security design
　　3. Gives the query optimizer a chance toread all the needed columns from the indexes
　　
DO know how your data willbe/is being acessed
　　
　　A robust indexdesign is one of the good things you can do for your database. And doing thisis almost an art form. Everytime you add an index to a table, things get fasteron SELECT, but INSERT and DELETE will be much slower. There's a lot of work inbuildingand mantaining indexes. If you add several indexes to a table to speedyour SELECT, you'll soon notice locks being held for a long time while updatingindexes. So, the question is: what is being done with this table? Reading orUpdating data? This question istricky, specially with the DELETE and UPDATE,because they often involve a SELECT for the WHERE part and after this theyupdate the table.
DON'T create an index on the"Sex" column
　　
　　This is useless.First, let's understand how indexes speed up table access. You can see indexesas a way of quickly partitioning a table based on a criteria. If you create anindex with a column like "Sex", you'll have only two partitions: Maleand Female. Whatoptimization will you have on a table with 1,000,000 rows?Remember, mantaining an index is slow. Always design your indexes with the mostsparse columns first and the least sparse columns last, e.g, Name + Province +Sex.
DO use transactions
　　
　　Specially onlong-running queries. This will save you when things get wrong. Working withdata for some time you'll soon discover some unexpected situation which willmake your stored procured crash.
DO beware of deadlocks
　　
　　Always accessyour tables on the same order. When working with stored procedures andtransactions, you may find this soon. If you lock the table A then table B,always lock them in this very same order in all stored procedures. If you, byaccident, lock thetable B and then table A in another procedure some day you'llhave a deadlock. Deadlocks can be tricky to find if the lock sequence is notcarefully designed.
DON'T open large recordsets
　　
　　A common requeston programming forums is: "How can I quickly fill this combo with 100,00items?". Well, this is an error. You can't and you shouldn't. First, youruser will hate browsing through 100,000 records to find the right one. A betterUI is needed here,because you should ideally show no more that 100 or 200records to your users.
DON'T use server side cursors
　　
　　Unless you knowwhat your are doing. Client side cursors often (not always) put less overheadon the network and on the server, and reduce locking time.
DO use parametrized queries
　　
　　Sometimes I seein programming forums, questions like: "My queries are failing with somechars, e.g. quotes. How can I avoid it?". And a common answer is:"Replace it by double quotes". Wrong. This is only a workaround andwill still fail with other chars, andwill introduce serious security bugs.Besides this, it will trash the SQL Server caching system, which will cacheseveral similar queries, instead of caching only one. Learn how to useparameterized queries (in ADO, through the use of the Command Object, or inADO.NETthe SqlCommand) and never have these problems again.
DO always test with largedatabases
　　
　　It's a commonpattern programmers developing with a small test database, and the end userusing large databases. This is an error: disk is cheap, and performanceproblems will only be noticed when it's too late.
DON'T import bulk data withINSERT
　　
　　Unless strictlynecessary. Use DTS or the BCP utility and you'll have both a flexible and fastsolution.
DO beware of timeouts
　　
　　When querying adatabase, the default timeout is often low, like 15 seconds or 30 seconds.Remember that report queries may run longer than this, specially when yourdatabase grows.
DON'T ignore simultaneousediting
　　
　　Sometimes twousers will edit the same record at the same time. When writing, the last writerwins and some of the updates will be lost. It's easy to detect this situation:create a timestamp column and check it before you write. If possible, mergechanges.If there is a conflict, prompt the user for some action.
DON'T do SELECT max(ID) fromMaster when inserting in a Detail table.
　　
　　This is anothercommon mistake, and will fail when two users are inserting data at the sametime. Use one of SCOPE_IDENTITY, IDENT_CURRENT, and @@IDENTITY. Avoid@@IDENTITY if possible because it can introduce some nasty bugs with triggers.
DO Avoid NULLable columns
　　
　　When possible.They consume an extra byte on each NULLable column in each row and have moreoverhead associated when querying data. The DAL will be harder to code, too,because everytime you access this column you'll need to check
　　
　　I'm not sayingthat NULLs are the evil incarnation, like some people say. I believe they canhave good uses and simplify coding when "missing data" is part ofyour business rules. But sometimes NULLable columns are used in situations likethis:
　　
　　CustomerName1
　　CustomerAddress1
　　CustomerEmail1
　　CustomerName2
　　CustomerAddress2
　　CustomerEmail3
　　CustomerName1
　　CustomerAddress2
　　CustomerEmail3
　　
　　This ishorrible. Please, don't do this, normalize your table. It will be more flexibleand faster, and will reduce the NULLable columns.
DON'T use the TEXT datatype
　　
　　Unless you areusing it for really large data. The TEXT datatype is not flexible to query, isslow and wastes a lot of space if used incorrectly. Sometimes a VARCHAR willhandle your data better.
DON'T use temporary tables
　　
　　Unless strictlynecessary. Often a subquery can substitute a temporary table. They induceoverhead and will give you a big headache when programming under COM+ becauseit uses a database connection pool and temporary tables will last forever. InSQL Server 2000,there are alternatives like the TABLE data type which canprovide in-memory solutions for small tables inside stored procedures too.
DO learn how to read a queryexecution plan
　　
　　The SQL Serverquery analyzer is your friend, and you'll learn a lot of how it works and howthe query and index design can affect performance through it.
DO use referential integrity
　　
　　This can be agreat time saver. Define all your keys, unique constraints and foreign keys.Every validation you create on the server will save you time in the future.
　　Conclusion
　　
　　As I've saidbefore, this is by no means a complete SQL Server performance and bestpractices guide. This would take a complete book to cover. But I really believethat this is a good start, and if you follow these practices, surely you willhave much less troublein the future.