【发布时间】:2011-08-14 16:29:25
【问题描述】:
【问题讨论】:
标签: .net ado.net sqlcommand
【问题讨论】:
标签: .net ado.net sqlcommand
Prepare method is actually on DbCommand,所有派生自它的类都会选择它。
它的作用是特定于DbCommand 所针对的数据库提供者。但是,可以肯定地说(尽管不是绝对规则),在大多数地方,如果命令是存储过程,它将产生一个无操作(它被记录为override of Prepare on SqlCommand),因为存储过程通常有他们的查询计划由于之前的调用、显式调用优化或创建时(同样取决于底层数据库)而优化。
但是,如果您不使用存储过程,而是使用动态生成的参数化查询,那么此调用将使底层数据库有机会生成优化版本的查询。
当您知道要在短时间内多次执行命令时,通常会执行此操作(实际上,这取决于数据库以及查询计划的缓存时间)。
应该说明的是,SQL Server(截至 2005 年,IIRC)根据第一次执行后的使用情况缓存参数化查询计划(我认为缓存是一个时间降级缓存,它会重置或在随后的使用),因此如果您要使用相同的参数化查询进行多次调用,那么调用Prepare 可能不会获得太多收益,而不是提前移动查询准备工作(这也可能是一个好处,具体取决于你要做什么工作)。
【讨论】:
更多信息可以在here找到。
但是,请记住:
在 SQL Server 中,准备/执行 模型没有显着的性能 优于直接执行, 因为 SQL Server 重用的方式 执行计划。 SQL Server 有 高效的匹配算法 当前执行的 SQL 语句 为之前生成的计划 执行相同的 SQL 语句。 如果应用程序执行 SQL 带有参数标记的语句 多次,SQL Server 将重用 从一开始的执行计划 执行第二次和 随后的执行(除非计划 来自过程缓存的年龄)。这 准备/执行模型仍然有这些 好处:
找到一个执行计划 识别句柄更高效 比用于匹配的算法 对现有执行的 SQL 语句 计划。
应用程序可以控制何时 创建执行计划以及何时创建执行计划 被重复使用。
准备/执行模型是可移植的 到其他数据库,包括更早的 SQL Server 的版本。
【讨论】:
通常,当您执行查询时,它会从解析字符串到运行执行计划一路走来。通过调用Prepare,它会尽可能地将进程带向执行,而不实际运行执行计划。
这在反复运行相同的命令时很有用。您将节省一些执行时间,因为整个过程不必每次都重复。
【讨论】: