C# 为什么要设置命令对象参数的大小参数？

我们的数据访问层使用命令对象与SQLServer通信

在大多数情况下，我已将字段大小（与sql server中的列大小相匹配）硬编码到命令param builder中

例如：

SqlParameter param = new SqlParameter("@name", NVarChar, 4000);

---

在这里指定一个值（本例中为4000）与仅将其保留为0相比有什么优势？当列大小发生变化时必须重新编译时，这是一种痛苦。

没有性能或执行时间优势-：

如果未在Size参数中显式设置，则从dbType参数的值推断大小

---

我想您可以这样说，通过显式声明参数的大小以匹配SQL Server中字段的大小，您可以更好地告知代码的读者数据模型的限制。从旁观者的角度看，这可能有多有用。

如果您指定的大小与SQL列的宽度匹配，那么您可能有另一个层来检测和/或防止数据丢失。（当用户输入或应用程序生成的字符数超过数据库中存储的字符数时会发生什么情况？）

---

也许问题与所有Microsoft缓冲区溢出有关？

实际上非常重要。使用不同参数长度发出的相同请求在过程缓存中以不同查询结束。最终，这会导致缓存污染和过度活跃的编译事件。这个问题是Linq2SQL和EF提供程序实现方式中的主要设计缺陷之一，例如，请参阅。另请参阅以了解相关问题。

varchar参数如何？推断的大小不只是指int和其他固定的len类型吗？不，大小是从数据而不是数据库中的字段推断出来的。所有数据都有一个大小。你愿意说出一些“所有那些缓冲区溢出”吗？几年前，微软软件中出现了一系列（非常）公开披露的安全漏洞，据说其中很多（如果不是大多数的话）都是基于缓冲区溢出的。（你不可能一个月都听不到另一个问题被发现。）最终，比尔·盖茨宣布，微软未来几个月的开发工作将完全集中于解决这些和类似的问题。我从未为微软工作过，也没有他们正在处理的问题的具体例子，它们可能不是由这里描述的确切情况产生的。我只是把它作为一个参考，如果在代码模块之间传递的值（字符串）的定义不匹配，可能会出现各种问题。这里我看到了两种情况-如果使用链接服务器（我不是），请指定字符串param的长度以匹配定义，否则请指定parcular类型的最大大小-对于nvarchar为4000，对于varchar为8000。执行计划缓存是有意义的。因此，这就引出了一个问题：为varchar（max）提供什么？2147483647？对于所有MAX类型，参数长度应为

-1

。