应该编译哪种类型的Linq to SQL查询

我以前遇到过这种情况。编译查询是一件很棒的事情，它确实能显著提高性能。但这并不总是最好的解决方案。

我正在写一些报告，花了30-40分钟来运行。我发现，某些查询我们调用了成百上千次。编译查询确实改进了一些东西，但还远远不够。

我最终做的是运行更少的查询，返回更多的数据。这是较少的开放和关闭的联系。结果是报告在不到一分钟的时间内运行。

因此，如果您必须多次运行查询，编译它是一个很好的选择。如果它运行了成百上千次，你可能需要一种新的方法。

关于这两件事的一些帖子:

SQL查询优化:不同的方法:

http://www.foliotek.com/devblog/sql-query-optimization-for-reporting-a-different-approach/

Linq中预编译查询的意外好处:

http://www.foliotek.com/devblog/unexpected-benefits-of-precompilation-of-linq/

还要考虑的是数据库上的索引。你的查询很慢，但你不知道为什么慢。如果它在未索引的列上进行搜索，那么这也可能是您的问题。

小心过早优化!

除非你已经分析了你的应用程序，并确定你将花费大量的时间来创建查询，否则开发人员的时间和简单性、可维护性和灵活性的降低是不值得的。

即使您在查询构造上花费了大量时间，也要注意预编译查询将通过一个相对较小的常数而不是数量级减少它们的运行时间。因此，从考虑程序更改(如纳尼亚提到)或缓存技术开始，以减少实际上必须首先运行这些查询的次数。

一旦你这样做了，仍然发现在编写查询时存在瓶颈，很可能你90%的时间花在了你正在运行的大约5%(或更少)的查询上。优化这些查询

更新

实体框架的现代实现现在已经内置了查询缓存，所以只要使用。net的现代版本，你就可能获得预编译查询所能提供的90%的好处。因此，更不必担心更改代码结构以适应理论上的性能提升。

如果您有类似的查询反复运行，您可以通过编译它们来提高性能。

有一些注意事项:http://omaralzabir.com/solving_common_problems_with_compiled_queries_in_linq_to_sql_for_high_demand_asp_net_websites/