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