这是关于SqlCommand.Prepare()的{{3}}：
创建一个准备好的版本 命令在SQL Server实例上。
任何人都能更深入地了解这意味着什么以及何时应该使用它？
答案 0 :(得分：13)
Prepare method is actually on DbCommand，从中获取的所有类都会被提取。
它所执行的操作特定于DbCommand所针对的数据库提供程序。但是，可以肯定地说（尽管不是绝对的规则），在大多数地方，如果命令是一个存储过程，它将产生一个no op（它被记录为override of Prepare on SqlCommand），作为存储过程由于先前调用，显式调用优化或创建（同样，取决于底层数据库），通常会优化其查询计划。
但是，如果您不使用存储过程，而是即时生成参数化查询，那么此调用将为底层数据库提供生成优化版本的机会查询。
当你知道要在很短的时间内多次执行命令时（通常，它取决于数据库，以及缓存查询计划的时间），你通常会这样做。
应该说SQL Server（截至2005年，IIRC）根据第一次执行后的使用情况来缓存参数化查询计划（我认为缓存是一个时间降级的缓存，它会重置或者随后的衰减速度变慢因此，如果您打算使用相同的参数化查询进行多次调用，那么除了预先调动查询准备工作之外，调用Prepare可能无法获得太多收益（这可能也是一个好处，取决于你必须完成的工作）。
答案 1 :(得分：10)
可以找到更多信息here。
但是，请记住：
在SQL Server中，准备/执行 模型没有显着的表现 优于直接执行， 因为SQL Server重用的方式 执行计划。 SQL Server有 有效的匹配算法 当前执行的SQL语句 为先前生成的计划 执行相同的SQL语句。 如果应用程序执行SQL 带参数标记的语句 多次，SQL Server将重用 从第一个执行计划 执行第二次和 随后的处决（除非计划 来自程序缓存的年龄）。该 准备/执行模型仍然有这些 好处：
通过查找执行计划 识别句柄更有效 比用于匹配的算法 SQL语句到现有执行 计划。
应用程序可以控制何时 创建执行计划以及何时执行 被重用。
准备/执行模型是可移植的 到其他数据库，包括早些时候 SQL Server的版本。
答案 2 :(得分：2)
通常，当您执行查询时，从解析字符串到运行执行计划一直都是如此。通过调用Prepare，它将尽可能地执行该过程而不实际执行执行计划。
当反复运行相同的命令时，这很有用。您将节省一些执行时间，因为每次都不必重复整个过程。