不要使用游标
不知你是否知道每执行一次FETCH就等于执行一次SELECT命令？这意味着如果你的光标有10000条记录，它将执行10000次SELECT！
我曾经用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查询分析器是你的好伙伴，通过它你可以了解查询和索引是如何影响性能的。
使用参照完整性
定义主健、唯一性约束和外键，这样做可以节约大量的时间。