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

Question

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

Answer 1

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

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

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

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

Answer 2

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

  

    

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

  

不，不。将用户输入的值硬编码到SQL语句中，但您也可以使用存储过程执行此操作。

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

  

    

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

  

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

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

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

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

LINQ还具有优于SP的优势，即将所有代码放在一个位置，而不是分散在两台不同的机器上。

Answer 3

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

他可能是一个MS人，但他被称为表演坚果 - 他的基准是彻底的，经过深思熟虑。

Answer 4

这是Maximilian Beller的表演。根据他的说法，LINQ慢得多。 Read his comprehensive study

Answer 5

考虑更改列名称 - 现在更改（n）SP和（x）视图。

在数据库上做一切昂贵的事情（比如搜索，排序等等），你就不会发现问题了。

另外，如果你想显示一个没有分页的大网格......那就使用一个数据集 - 那个更快。

StackOverflow也使用linq2sql - 你看到一个问题:)？

使用ORM - 这是继续使用大多数应用程序的方法。

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

Answer 6

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

如果您的数据库位于同一台计算机上或正式“连接良好”，那么最好使用它。

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

Answer 7

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

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

这并不是说你不能用LINQ构建一些真正无法维护的代码 - 没有人会阻止你在脚下射击但是你 - 但是如果做得好，LINQ可以提供很大的帮助。但是，我并不是说LINQ是一颗银弹。它有许多问题，使其难以在许多企业情况下使用 - 这就是MS提供实体框架（ADO.NET 3.0）的原因。当然，鉴于最近的EF Vote of No Confidence，即使这并不完美。

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