有没有办法使用存储过程在 linq2sql 中执行准备好的语句？
据我所知，答案是否定的，但总有可能
Based on what I can see the answer is no, but there is always a possibility
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
据我所知，答案是否定的，但总有可能
Based on what I can see the answer is no, but there is always a possibility
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（1）
存储过程在执行时进行编译，然后将执行计划存储在 SQL Server 维护的执行计划缓存中。除非基础表发生一些重要更改（例如更新的统计信息、新索引、手动请求重新编译等），否则它将使用存储的执行计划。
Linq-to-SQL 即席查询使用 sp_executesql 存储过程。这样做的结果是它们也存储在 SQL Server 的执行计划缓存中，因此多次运行相同的查询*只会导致 SQL Server 编译一次，然后使用缓存的计划。 （* = 具有相同数量和相同类型参数的相同查询）
也就是说，Linq-to-SQL 在将 linq 表达式树转换为 SQL 查询时也做了一定量的工作。其开销各不相同，但对于频繁执行的非常复杂的查询来说，这可能是值得注意的。
为了降低重复将同一查询转换为 SQL 的成本，Linq-to-SQL 有一个名为 CompiledQuery.不幸的是，CompiledQuery 类仅支持每个查询最多四个参数，因此对于复杂查询（它比非常简单的查询产生更大的影响），由于此限制，它通常被排除作为一个选项。还值得注意的是，CompiledQuery SQL 查询不利用 L2S 客户端谓词消除，因此如果您使用 CompiledQuery 类，则值得比较 SQL 服务器端成本（尤其是 I/O 方面），如果您有任何可能在客户端被消除的 where 子句谓词...
Stored procedures are compiled when executed, and the execution plan is then stored in an execution plan cache that SQL Server maintains. Unless there is some important change to the underlying tables (e.g. updated statistics, new indexes, manual request for recompilation etc) it will use the stored execution plan.
Linq-to-SQL ad-hoc queries use the sp_executesql stored procedure. The result of this is that they too are stored in SQL Server's execution plan cache, so running the same query* multiple times will only lead to SQL Server compiling it once and thereafter using the cached plan. (* = same query as in same number and same type of parameters)
That said, Linq-to-SQL also does a certain amount of work when translating the linq expression trees into SQL queries. The overhead of this varies but for very complex queries that are executed frequently this can be noticable.
To lower the cost of repeatedly translating the same query to SQL, Linq-to-SQL has something called CompiledQuery. Unfortunately the CompiledQuery class only support up to four parameters per query so for complex queries [where it would have a greater impact than it does on very simple queries] it is usually ruled out as an option due to this limitation. It is also worth noting that CompiledQuery SQL queries do not take advantage of L2S client-side predicate elimination so if you use the CompiledQuery class it is worth comparing the SQL-server-side cost (esp. in terms of I/O) if you have any where clause predicates that could potentially be eliminated client side...