可能是重复问题:
在 C# 中使用 SqlCommand Prepare 的优缺点?
这是 MSDN 关于 SqlCommand.Prepare()
的说法:
在 SQL Server 实例上创建命令的准备版本。
有人能提供更多关于这意味着什么以及何时应该使用它的见解吗?
可能是重复问题:
在 C# 中使用 SqlCommand Prepare 的优缺点?
这是 MSDN 关于 SqlCommand.Prepare()
的说法:
在 SQL Server 实例上创建命令的准备版本。
有人能提供更多关于这意味着什么以及何时应该使用它的见解吗?
Prepare
方法实际上在DbCommand
上, 所有从它派生的类都会使用它。
它所做的事情是特定于DbCommand
所属的数据库提供程序。但是,可以肯定地说(虽然不是绝对规则),在大多数情况下,如果命令是存储过程,则会产生无操作(对于SqlCommand
上的Prepare
重写已经记录为这样),因为存储过程通常由于之前的调用、显式调用优化或创建时(再次取决于底层数据库)而优化了其查询计划。
但是,如果您没有使用存储过程,而是在运行时生成参数化查询,则此调用将使底层数据库有机会生成查询的优化版本。
当您知道要在短时间内多次执行命令时,通常会这样做(这实际上取决于数据库以及查询计划缓存的时间长度)。
应该指出,SQL Server(截至2005年,如果我没记错的话)根据第一次执行后的使用情况缓存参数化查询计划(我认为缓存是一个时间衰减的缓存,随着后续使用而重置或其衰减速率减慢),因此,如果您要使用相同的参数化查询进行多个调用,则可能不会通过调用Prepare
获得太多优势,除了将查询准备工作前置(这也可能是一个好处,具体取决于您需要执行的工作内容)。更多信息可以在这里找到。
然而,请注意:
在SQL Server中,准备/执行模型与直接执行相比没有显著的性能优势,因为SQL Server重复使用执行计划的方式。 SQL Server具有高效的算法,可将当前SQL语句与为先前执行相同SQL语句生成的执行计划进行匹配。如果应用程序多次执行带参数标记的SQL语句,则SQL Server将从第一次执行中重用执行计划以供第二次和后续执行使用(除非缓存过程的计划老化)。 准备/执行模型仍���具有以下优点:
通过标识句柄查找执行计划比用于将SQL语句与现有执行计划匹配的算法更有效。
应用程序可以控制何时创建执行计划以及何时重用执行计划。
准备/执行模型可移植到其他数据库,包括早期版本的SQL Server。
通常情况下,当您执行查询时,它会从解析字符串一直运行到执行计划。通过调用Prepare
,它将尽可能地向执行前进,而不实际运行执行计划。
当反复运行相同的命令时,这非常有用。您可以节省一些执行时间,因为不必每次都重复整个过程。