主页 / dba / 问题 / 338742
Accepted
questionto42
Asked: 2024-04-18 00:36:47 +0800 CST

为什么你应该总是写“varchar”并在其后面的括号中包含长度？通常，您无需这样做就能得到正确的结果

  • 772

“通常，即使不这样做，你也会得到正确的结果。”

例子：

select CONVERT(varchar, getdate(), 112)

输出

20240417

我在 Stack Exchange 上的很多地方都看到了这一点，直到我发现了一个小注释，告诉读者不要忘记括号中的长度。我声称，如果您为这样的日期时间设置样式编号，则不需要这样做。然而，我现在有了足够的洞察力来理解“varchar 永远不应该独立”，它应该总是写成类似varchar(1234).

至于上面的代码，那就是：

select CONVERT(varchar(8), getdate(), 112)

如果你看一下，输出是相同的：

20240417

下面的评论更进一步：char(8)应该采取因为

样式 112 中的任何值都不会少于 8 个字符。

为什么写 varchar 时总是要把长度放在后面的括号里呢？

导致此问题的链接

sql-server

2 个回答

  1. Best Answer

    为什么你仍然应该总是写 varchar 并将长度放在后面的括号中？通常，您无需这样做就能得到正确的结果。

    经常和总是是两个截然不同的事情。

    例子：

    DECLARE @bin VARBINARY(200) = CAST('I have a lovely bunch of coconuts' AS varbinary(200))

select convert(varchar, @bin)

    输出缺失uts

    我有一束可爱的椰子

    这是由于默认行为：

    当数据定义或变量声明语句中未指定n时，默认长度为 1。如果使用and函数时未指定n，则默认长度为 30。CASTCONVERT

    这意味着定义中没有字节数的任何东西充其量都是一个最终的错误，最坏的情况是导致没有人知道的数据丢失。

    另请注意，n表示字节varchar(n)数，而不是字符数：

    一个常见的误解是认为char(n)和varchar(n)中的 n定义了字符数。但是，在char(n)和varchar(n)中，n定义字符串长度（以字节为单位）（0 到 8,000）。n从不定义可以存储的字符数。这类似于nchar(n)和nvarchar(n)的定义。

    之所以会产生这种误解，是因为使用单字节编码时， char 和 varchar 的存储大小为n 个字节，字符数也是n。但是，对于多字节编码（例如UTF-8 ），较高的 Unicode 范围（128 到 1,114,111）会导致一个字符使用两个或更多字节。

    例如，在 UTF8 排序规则上下文中，以下命令返回 16：

    SELECT DATALENGTH('😎😎😎😎');

    要存储该字符串，您至少需要varchar(16)，而不是varchar(4)。

    • 8

  2. 不设置 varchar 的长度很普遍，请参见示例1/1/1753 在 SQL Server 中的意义是什么？投票最高的答案显示，SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)经过 13 年和 171,000 次观看后，没有人抱怨它。然而，广泛传播并不总是意味着良好。

    为什么要把长度放在every varchar后面？

    DECLARE @x varchar = CONVERT(varchar, getdate(), 112);
select @x
select CONVERT(varchar(8), getdate(), 112)

    出去：

    20240417

    我认为不需要，8因为输出长度可能由 style 设置112。然而， @AaronBertrand在将日期 yyyy-mm-dd 转换为整数 YYYYMM下的评论显示：

    如果样式可以更正长度，那么这将按预期工作：
    DECLARE @x varchar = CONVERT(varchar, getdate(), 112);
    但这只返回单个字符2 [而不是20240417]（并且FORMAT 也无法拯救您）。问题是 SQL Server 已经为您决定了，在varchar(1)您分配任何内容之前，这需要很长时间，并且某些样式编号不会改变它的想法。

    另一条评论甚至要求你采取char而不是varchar如果你确定它必须一直是那个长度：

    你知道你想要 6 个角色吗？然后键入char(6)而不是varchar/* 键入很难 */。没有理由不明确（或使用 varchar 来实现固定长度），并且有充分的理由要小心。

    他的博客Bad Habits to Kick: Varchar without length深入展示了为什么应该将长度写在 any 后面的括号中varchar：

    因为 length 属性是可选的，所以人们似乎假设在 T-SQL 中定义 varchar 就像在 C# 中定义字符串：“它只会扩展为您填充到其中的任何大小。” 问题是，如果你不定义长度，SQL Server 会为你分配一个长度，但它可能不是你期望的长度。在某些情况下，它会是1；在其他方面，30.

    • -1

相关问题