Есть ли разница в скорости между использованием EXEC sp_executesql и прямым SQL

Если бы это был большой запрос, будет ли он быстрее во второй хранимой процедуре?Есть ли разница в скорости между использованием EXEC sp_executesql и прямым SQL

CREATE PROCEDURE Customers_GetCustomer 
     @CustId CHAR(5) 
AS 
BEGIN 
     DECLARE @SQL NVARCHAR(2000) 
     SET @SQL = 'SELECT ContactName FROM Customers WHERE CustomerId = @CustomerId' 
     EXEC sp_executesql @SQL, N'@CustomerId CHAR(5)', @CustomerId = @CustId 
END

Versus:

CREATE PROCEDURE Customers_GetCustomer 
     @CustId CHAR(5) 
AS 
BEGIN 
     SELECT ContactName FROM Customers WHERE CustomerId = @CustId 
END

источник

2017-02-02 Frédéric Fect

Динамический SQL должен анализироваться при каждом вызове (хотя план выполнения может быть спрятан). Обычный SQL можно просто скомпилировать напрямую. Если вы выполняете транзакции, это может быть проблемой. Если ваши запросы немного сложнее, то дополнительные усилия для компиляции, вероятно, не являются проблемой. –

Различия в производительности незначительны, но вы не должны использовать динамический sql, если на самом деле это не нужно, потому что это затрудняет работу. Это приводит к выводу, что это действительно не имеет большого значения. Если вам нужен динамический sql, вы не можете использовать стандартный запрос. –

С помощью простого запроса, как это, не будет практически никакой разницы даже в 1000х казнях/сек. (Основываясь на моем собственном тестировании, когда у меня был тот же вопрос.)

Предполагая, что он правильно настроен, сложный запрос будет иметь дополнительные накладные расходы для хэширования более длинной строки в соответствии с кешем выполнения.

Но я бы предложил проверить его самостоятельно, например, с помощью https://www.brentozar.com/archive/2015/05/how-to-fake-load-tests-with-sqlquerystress/.

источник

2017-02-02 15:16:42

Есть ли разница в скорости между использованием EXEC sp_executesql и прямым SQL

ответ

Смежные вопросы