表变量列中的nvarchar(max)与nvarchar(n)

Question

在最终向用户呈现结果集之前,我对表变量做了很多工作.例如,我可能从许多不同的表中拉入一大堆列,如下所示:

DECLARE @tmp TABLE
(
ID int,
username nvarchar(50),  -- data taken from tbl_Users
site nvarchar(50),      -- data taken from tbl_Sites
region nvarchar(100),   -- data taken from tbl_Regions
currency nvarchar(5)    -- data taken from tbl_Currencies
)

我花了很多时间浏览对象资源管理器以确保列的数据长度正确(与原始表匹配).有时,如果我更改表模式但不更新所有过程,我可能会遇到截断错误.

采取懒惰的做法是否有任何问题:

DECLARE @tmp TABLE
(
ID int,
username nvarchar(max),
site nvarchar(max),
region nvarchar(max),
currency nvarchar(max)
)

nvarchar(max)实际上是否会消耗更多内存或根据数据大小分配内存？还有其他陷阱吗？

请注意,我知道跳转到定义的第三方工具,但这不是我要求的.

UPDATE

重复的问题有价值,但问题不一样恕我直言.副本围绕实际表的设计而不是表变量.但是,答案中有一些优点,即:

• nvarchar(max)vs nvarchar(8000)在资源使用方面没有差异,直到8000+数据长度
• 业务逻辑层依赖于结构和有意义的数据,因此指定与原始值相称的列大小可提供值

从这个意义上讲,似乎可以nvarchar(max)在表变量中使用而不是nvarchar(n),但在某些环境中它具有可靠性和性能风险.如果你认为这应该被删除然后公平(但请停止争论我欣赏所有输入!)

Answer 1

我想不出任何理由nvarchar(max)在一个表变量中会有任何与在表中使用nvarchar(max)不同的陷阱(在这个问题中解释其缺点),除了陷阱由于表变量和临时/永久表之间的差异(例如,可怕的统计数据,没有二级索引等).Martin Smith在这里对表变量和临时表进行了很好的比较.

您仍然需要担心某些问题,例如,如果您使用古典技术(如经典ASP/ADO),您可能会发现必须最后列出MAX列以确保结果准确.我在2000年之前解释了这一点,然后才引入MAX类型 ; 但他们在那些旧供应商中遇到的问题与TEXT/相同NTEXT.你不太可能使用这种技术,但我想我会提到它以防万一.

不过,我建议你在编写代码时只需要点击并编写正确的类型.它们很容易从元数据中派生出来(例如sys.columns,右键单击表格并将脚本称为>创建到>剪贴板),这样做可以防止出现任何问题(例如上面提到的关于不匹配长度的@JC.可能导致上溢/截断).

另外,正如我之前暗示的那样,如果你有大量的行(感谢@Stuart),你应该考虑使用#temp表.我仍然认为无论你选择什么都应该明确.在这种情况下,将MAX用于所有事情的唯一好处是它可以让你变得懒惰,同时为你带来很大的风险.您编写一次代码,但是您的用户无数次地运行它.花费额外的几分钟来使您的数据类型正确,即使这意味着如果架构发生更改,您必须稍后更正两次.

至于内存使用情况nvarchar(max),是的,这可能会改变您的性能.有关证据,请参阅此博客文章.部分相关片段,我的拼写/语法更正:

因此,如果您确定nvarchar列的长度小于8000,则不要将列定义为nvarchar(max),而是尽可能将其定义为nvarchar(fixedlength).我看到使用固定长度的主要优点是:

内存授权可能是服务器已经内存不足的一个大问题.正如预期的行大小更多,优化器将估计更多的内存授予,这个值将远远高于实际需要,这将浪费像内存一样珍贵的资源.如果您有几个使用nvarchar(max)列的查询并且需要排序,则服务器可能存在与内存相关的问题.这可能是一个很大的问题.

他列出的其他优势与索引有关.无论如何,表变量都不是问题,因为您无法创建二级索引(在SQL Server 2014之前).

但是再一次,无论你从哪个类型的表结构中提取数据,这个潜在的问题都没有什么不同 - 临时表,表变量,永久表等.