LINQ To SQL 是否提供比使用 ado.net 和 oledb 更快的响应时间？答案

【问题标题】：Does LINQ To SQL provide faster response times than using ado.net and oledb?LINQ To SQL 是否提供比使用 ado.net 和 oledb 更快的响应时间？
【发布时间】：2009-01-16 01:28:04
【问题描述】：

LINQ 无疑简化了数据库编程，但它有缺点吗？内联 SQL 需要以某种方式与数据库通信，从而打开数据库以进行注入。内联 SQL 还必须进行语法检查，构建计划，然后执行，这需要宝贵的周期。在优秀的数据库应用程序编程中，存储过程也是一个坚如磐石的标准。我认识的许多程序员都使用简化开发的数据层，但是，不像 LINQ 那样。是时候放弃 SP 转而使用 LINQ 了吗？

【问题讨论】：

标签： sql-server database linq-to-sql

【解决方案1】：

LINQ to SQL 实际上在数据库中存在一些令人担忧的性能问题。基本上，它会根据您使用的参数的长度创建多个执行计划。我不久前在我的博客LINQ to SQL may cause performance problems 上发布了这件事。

现在，是不是说 LINQ 没有一席之地？几乎不。 LINQ 在开发工具包中肯定有一席之地，就像存储过程一样。最终，您希望在绝对需要性能时使用存储过程，并在任何其他情况下使用 ORM 工具。

就内联 SQL 而言，有多种方法可以执行内联 SQL，以便计划只构建一次并且永远不会重新编译。大多数 ORM 也应该注意性能调整的这一方面，并且使用这些方法通常是执行 SQL 的最安全方法，因为它会强制您使用参数化查询。

与大多数数据库解决方案一样，正确答案取决于您要解决的问题。如果您更喜欢开发速度而不是数据库/应用程序性能，那么使用 LINQ 或其他 DAL/ORM 工具是最好的方法。如果您更喜欢性能而不是易于开发，那么使用存储过程和纯数据集将是您最好的选择。 LLBLGen 甚至提供了一个 LINQ to LLBLGen 层，因此您可以使用 LINQ 查询 LLBLGen 的对象并让 LLBLGen 实际处理构建您的查询并避免 LINQ 的一些缺陷。

【讨论】：

【解决方案2】：

你的基本前提是有缺陷的..

内联 SQL 需要以某种方式与数据库通信，从而打开数据库以进行注入。

不，它没有。可以将用户输入的值硬编码到 SQL 语句中，但您也可以使用存储过程来做到这一点。

对查询进行参数化可以防止注入攻击，但内联 SQL 可以像存储过程一样轻松地进行参数化。

内联 SQL 还必须经过语法检查，构建计划，然后执行。

所有 Sql（SP 和内联）都必须经过语法检查，并在第一次调用时制定计划。此后，请求和执行计划的确切文本被缓存。如果收到另一个具有完全相同文本（不计算参数）的请求，则使用缓存的执行计划。

因此，如果您将值硬编码到内联 SQL 中，文本将不匹配，并且必须重新解析查询。但是，如果您使用参数，则查询的文本将匹配，并且您将获得缓存命中。在这种情况下，查询是内联 SQL 还是 SP 无关紧要。

换句话说，内联 SQL 的唯一问题是它很容易做一些缓慢且不安全的事情。但是，让内联 SQL 快速且安全不再是使用 SP 的工作。

这将我们带到了 LINQ，它始终使用参数，即使您将值硬编码到 LINQ 语句中，也使“快速和安全”的内联 SQL 变得微不足道。

与 SP 相比，LINQ 还具有将所有代码集中在一个位置而不是分散在两台不同机器上的优势。

【讨论】：

【解决方案3】：

如果您对基准测试感兴趣，Rico Mariani 的 excellent 5-part study 涵盖了定性和定量差异。

他可能是一名 MS 专家，但他被称为性能狂人 - 他的基准测试非常全面且经过深思熟虑。

【讨论】：

【解决方案4】：

这是马克西米利安·贝勒 (Maximilian Beller) 的表演。据他说，LINQ 要慢得多。 Read his comprehensive study

【讨论】：

仅供参考：您上面提到的链接现已失效。

【解决方案5】：

只需考虑更改列名称 - 现在更改 (n)SP 和 (x)Views。

在数据库上做所有昂贵的事情（如搜索、排序等），你不会注意到问题。

此外，如果您想在不分页的情况下显示大网格......然后使用数据集 - 那个更快。

StackOverflow 也使用 linq2sql - 你看到问题了吗 :)？

使用 ORM - 这是大多数应用程序的方式。

PS：另外，关于微基准测试 - 比如 .. 让我们使用 ORM 选择 10.000 行 - 不要这样做。这不是你使用 ORM 的原因。如果要选择 10.000 行，请使用 ADO。

【讨论】：

【解决方案6】：

这取决于你在做什么。 LINQ 在实际数据/集操作方面的效率将低于真实数据库。但是您不必通过网络连接到数据库会节省很多。

如果您的数据库在同一台机器上或正式“连接良好”，则最好使用它。

但是，如果您要从远程数据库返回一个大型结果集，这可能意味着大量的传输时间，或者如果它是一个非常短的查询，不能证明开销是合理的，那么 LINQ 可能会更好。

【讨论】：

【解决方案7】：

由于 LINQ to SQL 的结构，它不可能更快使用原始 SQL，无论是您自己的格式良好的查询还是作为存储过程。 LINQ 为您带来的不是速度，而是类型安全和组织；简而言之，ORM 通常授予您的大部分好处。

LINQ to SQL 不是关于速度，而是关于构建一个更易于维护的软件系统。这涉及到专门的软件工程师和架构师关心的所有东西，比如松散耦合和分层

这并不是说您不能使用 LINQ 构建一些真正难以维护的代码——除了你之外，没有人能阻止你自欺欺人——但是如果做得好，LINQ 可以提供极大的帮助。然而，我并不是说 LINQ 是灵丹妙药。它有许多问题使其难以在许多企业情况下使用——这就是 MS 提供实体框架 (ADO.NET 3.0) 的原因。当然，考虑到最近 EF 的不信任投票，即使这样也不完美。

LINQ to SQL 甚至 EF 是否比原始 SQL 更好？我会说一个响亮的地狱是的。还有其他可能效果更好的解决方案吗？也许。

【讨论】：