我有一个 SQL Server 2000 实例，它在一组 4 或 5 个表上运行多个并发选择语句。通常在这些查询期间，服务器的性能会变得非常低下。这些查询可能比同一查询的其他运行时间长 10 倍，甚至一些简单的操作（如在对象资源管理器中获取表列表或运行 sp_who）也可能需要几分钟。
我已尽最大努力找出这些问题的原因，我发现唯一不合理的性能指标是平均闩锁等待时间。我读到超过 1 秒的等待时间是不好的，而我的在重度使用的情况下，等待时间在 20 到 75 秒之间。
所以我的问题是，问题可能是什么？SQL 难道不应该能够在不损失太多性能的情况下处理单个表上的多个选择吗？有人能建议从这里去哪里调查这个问题吗？
谢谢您的帮助。
答案1
取决于锁定。大多数人完全忘记了关心锁定。标准连接设置完全读取锁定（可重复读取），这可能会耗尽资源。
如果您只读取，则只读取一次，请使用以某种方式标记的连接和以某种方式标记的 SQL 语句，以不留下任何锁。
适用于大多数 asp.net 页面 - 您阅读、显示页面...无需为此操作保持锁定，仅当您开始写入时才需要。
答案2
如果应用程序确实只对该表进行读取，则阻塞应该不是问题。我会：
- 确保表具有适合正在运行的查询的索引。其中一个索引应该是聚集索引。
- 确保索引已重建或表统计信息已在最近更新。
- 查看磁盘性能，这是一个常见问题。如果秒数/传输数超过几十毫秒，请尝试找到一种方法来最小化正在进行的 I/O 量（这通常意味着添加索引、更改表架构或更改查询），或提高磁盘子系统的性能。这可能意味着将文件移动到不同的磁盘上、更改 RAID 级别、调整 RAID 控制器策略等。
- 对于 SQL2000，我会确保处理器已禁用超线程。
答案3
SQL Server 2000 使用锁机制升级锁涵盖越来越多的架构 - 即，您可能开始锁定表的一页，但随着锁定的行越来越多，该锁定将很快升级为全表锁定。对于某些类型的查询，这绝对会降低性能。
以至于 MS 在后来的版本中将锁定机制改为更像 Oracle 的行级锁定。