十、不要使用服务器端游标

　　与服务器端游标比起来，客户端游标可以减少服务器和网络的系统开销，并且还减少锁定时间。

　　十一、使用参数查询

　　有时，我在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使编码变得复杂，因为每一次访问这些列时都必须先进行检查。