如果你正在负责一个基于SQL Server的项目或者你刚刚接触SQL Server你都有可能要面临一些数据库性能的问题这篇文章会为你提供一些有用的指导（其中大多数也可以用于其它的DBMS）
在这里我不打算介绍使用SQL Server的窍门也不能提供一个包治百病的方案我所做的是总结一些经验关于如何形成一个好的设计这些经验来自我过去几年中经受的教训一直来我看到许多同样的设计错误被一次又一次的重复
你了解你用的工具吗？
不要轻视这一点这是我在这篇文章中讲述的最关键的一条也许你也看到有很多的SQL Server程序员没有掌握全部的TSQL命令和SQL Server提供的那些有用的工具
什么？我要浪费一个月的时间来学习那些我永远也不会用到的SQL命令？？？你也许会这样说对的你不需要这样做但是你应该用一个周末浏览所有的TSQL命令在这里你的任务是了解将来当你设计一个查询时你会记起来对了这里有一个命令可以完全实现我需要的功能于是到MSDN查看这个命令的确切语法
不要使用游标
让我再重复一遍不要使用游标如果你想破坏整个系统的性能的话它们倒是你最有效的首选办法大多数的初学者都使用游标而没有意识到它们对性能造成的影响它们占用内存还用它们那些不可思议的方式锁定表另外它们简直就像蜗牛而最糟糕的是它们可以使你的DBA所能做的一切性能优化等于没做不知你是否知道每执行一次FETCH就等于执行一次SELECT命令？这意味着如果你的游标有条记录它将执行次SELECT！如果你使用一组SELECTUPDATE或者DELETE来完成相应的工作那将有效率的多
初学者一般认为使用游标是一种比较熟悉和舒适的编程方式可很不幸这会导致糟糕的性能显然SQL的总体目的是你要实现什么而不是怎样实现
我曾经用TSQL重写了一个基于游标的存储过程那个表只有条记录原来的存储过程用了分钟才执行完毕而新的存储过程只用了秒钟在这里我想你应该可以看到一个不称职的程序员究竟在干了什么！！！
我们可以写一个小程序来取得和处理数据并且更新数据库这样做有时会更有效记住对于循环TSQL无能为力
我再重新提醒一下使用游标没有好处除了DBA的工作外我从来没有看到过使用游标可以有效的完成任何工作
规范化你的数据表
为什么不规范化数据库？大概有两个借口出于性能的考虑和纯粹因为懒惰至于第二点你迟早得为此付出代价而关于性能的问题你不需要优化根本就不慢的东西我经常看到一些程序员反规范化数据库他们的理由是原来的设计太慢了可结果却常常是他们让系统更慢了DBMS被设计用来处理规范数据库的因此记住按照规范化的要求设计数据库
不要使用SELECT *
这点不太容易做到我太了解了因为我自己就经常这样干可是如果在SELECT中指定你所需要的列那将会带来以下的好处
减少内存耗费和网络的带宽
你可以得到更安全的设计
给查询优化器机会从索引读取所有需要的列
了解你将要对数据进行的操作
为你的数据库创建一个健壮的索引那可是功德一件可要做到这一点简直就是一门艺术每当你为一个表添加一个索引SELECT会更快了可INSERT和DELETE却大大的变慢了因为创建了维护索引需要许多额外的工作显然这里问题的关键是你要对这张表进行什么样的操作这个问题不太好把握特别是涉及DELETE和UPDATE时因为这些语句经常在WHERE部分包含SELECT命令
不要给性别列创建索引
首先我们必须了解索引是如何加速对表的访问的你可以将索引理解为基于一定的标准上对表进行划分的一种方式如果你给类似于性别这样的列创建了一个索引你仅仅是将表划分为两部分男和女你在处理一个有条记录的表这样的划分有什么意义？记住维护索引是比较费时的当你设计索引时请遵循这样的规则根据列可能包含不同内容的数目从多到少排列比如姓名 省份 性别
使用事务
请使用事务特别是当查询比较耗时如果系统出现问题这样做会救你一命的一般有些经验的程序员都有体会你经常会碰到一些不可预料的情况会导致存储过程崩溃
小心死锁
按照一定的次序来访问你的表如果你先锁住表A再锁住表B那么在所有的存储过程中都要按照这个顺序来锁定它们如果你（不经意的）某个存储过程中先锁定表B再锁定表A这可能就会导致一个死锁如果锁定顺序没有被预先详细的设计好死锁是不太容易被发现的
不要打开大的数据集
在CSDN技术论坛中 :）一个经常被提出的问题是我怎样才能迅速的将条记录添加到ComboBox中？这是不对的你不能也不需要这样做很简单你的用户要浏览条记录才能找到需要的记录他一定会诅咒你的在这里你需要的是一个更好的UI你需要为你的用户显示不超过或条记录
不要使用服务器端游标
与服务器端游标比起来客户端游标可以减少服务器和网络的系统开销并且还减少锁定时间
使用参数查询
有时我在CSDN技术论坛看到类似这样的问题SELECT * FROM a WHERE aid=AB因为单引号查询发生异常我该怎么办？而普遍的回答是用两个单引号代替单引号这是错误的这样治标不治本因为你还会在其他一些字符上遇到这样的问题更何况这样会导致严重的bug除此以外这样做还会使SQL Server的缓沖系统无法发挥应有的作用使用参数查询 釜底抽薪这些问题统统不存在了
在程序编码时使用大数据量的数据库
程序员在开发中使用的测试数据库一般数据量都不大可经常的是最终用户的数据量都很大我们通常的做法是不对的原因很简单现在硬盘不是很贵可为什么性能问题却要等到已经无可挽回的时候才被注意呢？
不要使用INSERT导入大批的数据
请不要这样做除非那是必须的使用UTS或者BCP这样你可以一举而兼得灵活性和速度
注意超时问题
查询数据库时一般数据库的缺省都比较小比如秒或者秒而有些查询运行时间要比这长特别是当数据库的数据量不断变大时
不要忽略同时修改同一记录的问题
有时候两个用户会同时修改同一记录这样后一个修改者修改了前一个修改者的操作某些更新就会丢失处理这种情况不是很难创建一个timestamp字段在写入前检查它如果允许就合并修改如果存在沖突提示用户
在细节表中插入纪录时不要在主表执行SELECT MAX(ID)
这是一个普遍的错误当两个用户在同一时间插入数据时这会导致错误你可以使用SCOPE_IDENTITYIDENT_CURRENT和@@IDENTITY如果可能不要使用@@IDENTITY因为在有触发器的情况下它会引起一些问题（详见这里的讨论）
避免将列设为NULLable
如果可能的话你应该避免将列设为NULLable系统会为NULLable列的每一行分配一个额外的字节查询时会带来更多的系统开销另外将列设为NULLable使编码变得复杂因为每一次访问这些列时都必须先进行检查
我并不是说NULLS是麻烦的根源尽管有些人这样认为我认为如果你的业务规则中允许空数据那么将列设为NULLable有时会发挥很好的作用但是如果在类似下面的情况中使用NULLable那简直就是自讨苦吃
CustomerName CustomerAddress CustomerEmail CustomerName CustomerAddress CustomerEmail CustomerName CustomerAddress CustomerEmail
如果出现这种情况你需要规范化你的表了
尽量不要使用TEXT数据类型
除非你使用TEXT处理一个很大的数据否则不要使用它因为它不易于查询速度慢用的不好还会浪费大量的空间一般的VARCHAR可以更好的处理你的数据
尽量不要使用临时表
尽量不要使用临时表除非你必须这样做一般使用子查询可以代替临时表使用临时表会带来系统开销如果你是用COM 进行编程它还会给你带来很大的麻烦因为COM 使用数据库连接池而临时表却自始至终都存在SQL Server提供了一些替代方案比如Table数据类型
学会分析查询
SQL Server查询分析器是你的好伙伴通过它你可以了解查询和索引是如何影响性能的
使用参照完整性
定义主健唯一性约束和外键这样做可以节约大量的时间
