c# - SQL 性能、.Net 优化与最佳实践

Question

我需要专业人士/大师的确认/解释如下，因为我的团队告诉我“没关系”，这让我很沮丧:)

背景:我们有一个 SQL Server 2008，我们的主 MVC3/.Net4 Web 应用程序正在使用它。在任何给定点，我们都有大约 200 多个并发用户。服务器受到了极大的打击(锁定、超时、整体缓慢)，我正在尝试应用我在整个职业生涯中以及在上一次 MS 认证类(class)中学到的东西。它们是我们一直在钻研的东西(“关闭 SQL 连接 STAT”)，我试图向我的团队解释这些“小东西”，虽然不是单独一个就能产生影响，但最终会加起来。

我需要知道以下内容是否会对性能产生影响，或者这只是“最佳实践”

1. 使用“USING”关键字。
他们的大部分代码是这样的:

public string SomeMethod(string x, string y) {
    SomethingDataContext dc = new SomethingDataContext();
    var x = dc.StoredProcedure(x, y);
}

虽然我试图告诉他们 USING 可以更快地关闭/释放资源:

using (SomethingDataContext dc = new SomethingDataContext()) {
    var x = dc.StoredProcedure(x, y);
}

他们的论点是 GC 在代码执行完毕后做了足够好的清理工作，所以 USING 没有太大影响。是真是假，为什么？

2.连接池

我一直听说设置连接池可以显着加快任何网站的速度(至少 .Net w/MSSQL)。
我建议我们将以下内容添加到 web.config 中的连接字符串中:

..."Pooling=True;Min Pool Size=3;Max Pool Size=100;Connection Timeout=10;"...

他们的论点是 .Net/MSSQL 已经在幕后设置了连接池，不需要放在我们的 web.config 中。对或错？如果已经设置了池，为什么每个其他站点都说应该添加池以获得最佳性能？

3. 尽量减少调用 DB 的次数

默认 .Net MVC 项目附带的 Role/Membership 提供程序很好 - 它很方便，可以为您完成大部分工作。但是这些家伙正在认真使用 UsersInRoles()并像全局变量一样自由地使用它(每次调用此方法时它都会命中数据库)。
我创建了一个“用户对象”，它在每个页面加载时预先加载所有角色(以及一些其他用户内容，例如 GUID 等)，然后查询该对象是否用户具有角色。

网站的其他部分有 FOR 语句，循环次数超过 200 次，每次传递执行 20-30 次 sql 查询 = 超过 4,000 次数据库调用。它以某种方式在几秒钟内完成此操作，但我想要做的是将 20-30 个 DB 调用合并为一个，以便 ONE 调用 200 次(每个循环)。
但是因为 SQL 分析器说查询花费了“0 秒”，他们的论点是它是如此之快和如此之小，以至于服务器可以处理这些大量的数据库查询。

我的想法是“是的，这些查询运行得很快，但它们正在扼杀 SQL 服务器的整体性能。”
这可能是一个促成因素吗？我是什么都不担心，还是这是服务器整体性能问题的(重要)促成因素？

4.其他代码优化

想到的第一个是使用 StringBuilder vs 一个简单的字符串变量。我明白为什么我应该使用 StringBuilder (尤其是在循环中)，但他们说这无关紧要——即使他们需要写 10k+ 行，他们的论点是性能增益无关紧要。

总而言之，我们学习并深入我们的所有东西(“最小化范围!”)只是“最佳实践”而没有真正的性能提升，还是它们都会导致真实/可衡量的性能损失？

编辑 ***
谢谢大家的回答!根据您的回答，我有一个新的(第 5 个)问题:
他们实际上不使用“USING”，那么这意味着什么？如果连接池自动发生，它是否会占用池中的连接直到 GC 出现？是否有可能每个打开的 SQL 服务器连接都会给服务器增加一点负担并减慢它的速度？

根据您的建议，我计划对连接时间进行一些严肃的基准测试/记录，因为我怀疑 a) 服务器很慢，b) 他们没有关闭连接，c) Profiler 说它在 0 秒内运行，速度很慢可能来自连接。

我真的很感谢你们的帮助。再次感谢

Answer 1

分支代码，根据当前代码库进行更改并对其进行基准测试+分析。然后，您将有一些证据来支持您的主张。

至于你的问题，这里是:

你应该总是手动处理实现 IDisposable 的类。 , GC 实际上不会调用 dispose 但是如果该类还实现了终结器那么它将调用终结器但是在大多数实现中它们只清理非托管资源。

确实，.NET 框架已经进行了连接池，我不确定默认值是什么，但连接字符串值将在那里允许您更改它们。

SQL 语句的执行时间只是故事的一部分，在 SQL Profiler 中，您将看到的是数据库引擎执行查询所花费的时间，您缺少的是 Web 服务器连接到所需的时间并从数据库服务器接收结果，因此虽然查询可能很快，但您可以通过批量查询节省大量 IO 和网络延迟。

这是一个很好的方法，可以进行一些分析以证明字符串构建器上的连接使用的额外内存。