Project Summary - Parameter setting length of SqlParameter (size attribute)

When I see many friends instantiating SqlParameter, they usually assign the parameter directly without specifying the length of the parameter. Like the following writing:

new SqlParameter("@address",SqlDbType.Varchar){Value=address};     

    In the past, I always felt that there should be no difference between adding and not adding the length of the parameter. It is only the difference in writing. It was not until I finished this project that I realized that the two are actually different. In order to improve the execution speed of SQL, please specify the SqlParameter parameter. Plus size attribute.

 

    Let's analyze the difference between the two:

    According to the MSDN explanation: If Size is not explicitly set in the size parameter, the size is inferred from the value of the dbType parameter .

If you think that the above inference refers to inferring the size from the SqlDbType type, then you are wrong. It is actually inferred from the value of the parameter you passed in. For example, the passed value is "shengzhen", then the size The value is 9, "shanghai", the size value is 8. So, what are the consequences of different size values? And the test found that when the value of size is different, the execution plan of the database will not be reused, so that a new execution plan will be regenerated every time sql is executed, and the execution time of the database will be wasted.

    for example:

 

string sql = "select top 1 * from table1 where address = @address";  
SqlParameter[] parameter = new SqlParameter("@address", SqlDbType.VarChar) {Value = "shanghai"};  
SqlHelper.ExecuteReader(ConnectionString, CommandType.Text, sql, parameter)  

 

 The sql we captured through the database tracking tool SqlProfiler is as follows:

 

exec sp_executesql N'select top 1 * from table1 where address = @address',N'@address nvarchar(8)',@address=N'shanghai'  

 

 If the value of the parameter is changed to shengzhen, the sql captured by SqlProfiler is as follows:

 

 

exec sp_executesql N'select top 1 * from table1 where address = @address',N'@address nvarchar(9)',@o=N'shengzhen'  

 

 Then use the following sql to test whether the execution plan is reused:

DBCC FREESYSTEMCACHE('ALL')  
DBCC FREEPROCCACHE  
GO  
exec sp_executesql N'select top 1 * from T_GroupInfo where groupName = @groupName',N'@groupName nvarchar(8)',@groupName=N'第1组'  
GO  
SELECT * FROM sys.dm_exec_cached_plans WHERE cacheobjtype = 'Compiled Plan'  
GO  
exec sp_executesql N'select top 1 * from T_GroupInfo where groupName = @groupName',N'@groupName nvarchar(9)',@groupName=N'第2组'  
GO  
SELECT * FROM sys.dm_exec_cached_plans WHERE cacheobjtype = 'Compiled Plan'  
GO  

 You will find that the first sql and the second sql will each generate their own execution plan, and if the length of the @address parameter is the same, the same execution plan will be used.

Summarize:

When instantiating SqlParameter, if it is a character type, be sure to specify the size attribute , such as the top definition, it should be modified to:

new SqlParameter("@address",SqlDbType.Varchar,4000){Value=address};      

If it is a parameter such as Int, Float, Bigint, DateTime, you can do not specify the size attribute. But if size is specified incorrectly, unpredictable errors may occur.

 

 

 

 

 

 

 

 

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324886495&siteId=291194637