SQL 性能大变量 Varchar 转换成小列

Question

将较大的 varchar 变量放入小列是否存在任何性能问题？我在执行计划中没有看到任何性能差异。只想验证。

例子，

create table dbo.Product
(
    ProductId int identity(1,1),
    ProductName varchar(25),
    ProductDescription varchar(255),

    constraint pk_ProductId Primary Key (ProductId)
)

案例 1 大 varchar(4000)

declare @ProductNameVar varchar(4000),@ProductDescriptionVar varchar(4000)

set @ProductNameVar = 'Table'
set @ProductDescriptionVar ='manufactured , oak table, round edges..' 

INSERT INTO dbo.Product(ProductName, ProductDescription) 
VALUES (@ProductNameVar, @ProductDescriptionVar)

案例 2 小型 Varchars

declare @ProductNameVar varchar(25),@ProductDescriptionVar varchar(255)

set @ProductNameVar = 'Table'
set @ProductDescriptionVar ='manufactured , oak table, round edges..' 

INSERT INTO dbo.Product(ProductName, ProductDescription) 
VALUES (@ProductNameVar, @ProductDescriptionVar)

Answer 1

性能真的是您最关心的问题吗？或者您只是在寻找借口而不去确保参数数据类型与列数据类型匹配？（这恰好是将所有内容声明为 的常见原因nvarchar(max)。）

您的参数应该完全匹配基础列类型。如果一个改变，你就改变两个。

为永远不会保存那么多数据的变量声明更大的数据类型可能是浪费，在性能方面，因为必须保留内存，以防以后更新变量。但是，恕我直言，这种性能差异（如果它甚至存在）完全无关紧要。

原因？如果有人将 26 个字符放入第一个变量，则插入将失败。并且错误消息是无用的：

消息 8152，级别 16，状态 14
字符串或二进制数据将被截断。
该语句已终止。

想象一下，你有 10 个不同长度的列和 10 个varchar(4000)参数，然后你调用这个存储过程 100 次，并得到 20 次错误？狩猎快乐！

为什么要邀请可预防的错误（或者至少可以在链的更上游发生）？您应该一直验证您的输入：

• 确保表单域不能超过 25 个字符（HTML 支持）；
• 确保客户端验证检查它不超过 25 个字符（JavaScript 支持）；
• 确保 .NET 数据类型声明为 25 个字符；并且，因为对你认为神圣的一切事物的热爱，
• 将该参数设为 25 个字符。

是的，当长度发生变化时，这需要做更多的工作，但恕我直言，其他任何事情都是不可原谅的。