是否应该在高流量的网站中使用LINQ to SQL？

Question

我已经阅读了很多关于linq to sql性能的文章。结果证明，与常规方法（DAL或Microsoft企业库）相比，linq to sql更慢。即使进行了性能调优，如禁用ObjectTracking和其他技巧，读写操作都会更慢。我知道它有快速开发、清晰的代码等优点，但性能如何呢？

如果只用于读取操作，会怎样呢？

请给出你的建议。

- Adeel

---

+1 我认为问题不在于 LINQ to SQL 本身，而是因为它非常深入，容易出错。在循环中误用集合属性可能会导致性能问题迅速恶化。 - Tj Kellie

Answer 1

对于stackoverflow来说，这似乎工作得足够好；-p 特别是如果您使用编译查询，与适当的数据库设计、获取正确的列/行以及避免n+1加载相比，这不太可能成为瓶颈。

- Marc Gravell

---

@Gravel && @Byers，有一个问题。假设我们有3个服务器。1个用于读取，1个用于写入，另一个是复制服务器。那么如果我使用LINQ进行读取操作，并手动编写查询进行写入操作，这是否是最佳解决方案？还是有其他更好的解决方案？你们有什么建议？ - Adeel

@Adeel - 数据库服务器还是应用服务器？听起来你是指数据库服务器 - 但我不确定使用的特定数据访问API是否会产生巨大的差异（与不同的数据库设置相比）。 - Marc Gravell

@Gravel服务器指的是数据库服务器。由于Linq方法在写操作方面比数据访问API慢得多，而对于读取操作，性能开销可以忽略不计。因此，仅在读取目的时使用Linq是否更好？ - Adeel

@Adeel -肯定读比写好；然而，这取决于具体情况；大多数代码不会发出大量的DML。如果确实需要这样做，则命令批处理是理想的选择，但您也可以考虑将数据批量传输到数据库中（例如xml或SqlBulkCopy，或在SQL 2008中使用表值参数），并使用基于集合的更新/插入在数据库中进行处理。其中只有前者可通过L2S获得。 - Marc Gravell

@Adeel：这取决于你需要执行的具体查询。我会先尝试使用LINQ来测量实际性能，然后再放弃并选择其他技术。在许多情况下，它对读写都很有效。但是你说你已经测量过了，并发现它要慢得多。我可能会再次检查它实际发送到数据库的查询，看看是否存在明显的问题可以轻松解决，并进行一些性能测量以确定时间的消耗位置，但除此之外，我认为你已经得到了答案。 - Mark Byers

@Adeel：我建议使用Marc建议的SqlBulkCopy，同时尝试我链接的批量更新/删除实现，然后基准测试它们的性能。如果没有尝试，我同意Mark的说法，现在放弃太早了。我正在为自己的测量目的实施此功能，但还没有时间去做，所以我没有数据可以分享。尽管如此，如果将其缩小为1个查询，性能没有提高，我会感到惊讶。 - Ahmad Mageed

Answer 2

对于读操作，LINQ To SQL 的速度应该与直接编写 SQL 相当快，因为这正是它所做的。创建 SQL 的开销不应该被注意到。可能会有一些查询无法像手动编写查询那样优化，但在我看来，在大多数情况下它表现得非常好。

对于批量更新，LINQ To SQL 通常较慢，因为它逐个处理行。您不能像 LINQ to SQL 中那样执行 UPDATE Foo SET x = 0 WHERE id BETWEEN 100 AND 200 这样的操作而不获取所有行。目前最好手动编写 SQL 来处理此类操作。

- Mark Byers

Answer 3

更新和删除是LINQ to SQL目前存在问题的地方，因为每个受影响的对象都会生成一个单独的语句。

话虽如此，这篇博客详细介绍了如何将这两个操作缩减到1个语句，这应该有助于提高性能：使用LINQ to SQL进行批量更新和删除。

编译查询对于经常使用的查询也很有用，特别是那些使用参数来获取特定结果的查询。您可能还会发现这篇博客有帮助：10个改善LINQ to SQL应用程序性能的提示。

- Ahmad Mageed