我相信guid被限制为16字节的长度(或32字节的ASCII十六进制等效)。

guid是128位，或者

0 through ffffffffffffffffffffffffffffffff (hex) or 
0 through 340282366920938463463374607431768211455 (decimal) or 
0 through 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 (binary, base 2) or 
0 through 91"<b.PX48m!wVmVA?1y (base 95)

是的，最小20个字符长，这实际上浪费了超过4.25位，所以你可以使用比95个更小的基数;以85为基数的十进制十进制十进制十进制十进制十进制十进制十进制十进制十进制十进制十进制十进制十进制十进制十进制

0 through -r54lj%NUUO[Hi$c2ym0 (base 85, using 0-9A-Za-z!"#$%&'()*+,- chars)

:-)

22字节，如果你这样做:

System.Guid guid = System.Guid.NewGuid();
byte[] guidbytes = guid.ToByteArray();
string uuid = Convert.ToBase64String(guidbytes).Trim('=');

这里要做的正确的事情是将它存储为uniqueidentifier—然后在数据库中完全可索引等等。次优选择是二进制(16)列:标准guid的长度正好是16字节。

如果您必须将其存储为字符串，那么长度实际上取决于您选择如何编码它。作为没有连字符的十六进制(又名base-16编码)，它将是32个字符(每个字节两个十六进制数字)，因此char(32)。

但是，您可能希望存储连字符。如果你的空间不足，但你的数据库本身不支持blobs / guids，你可以使用Base64编码并删除==填充后缀;这给了你22个字符，那么char(22)没有必要使用Unicode，也没有必要使用可变长度-例如，因此nvarchar(max)将是一个糟糕的选择。

这取决于你如何格式化Guid:

Guid.NewGuid().ToString() = 36 characters (Hyphenated) outputs: 12345678-1234-1234-1234-123456789abc Guid.NewGuid().ToString("D") = 36 characters (Hyphenated, same as ToString()) outputs: 12345678-1234-1234-1234-123456789abc Guid.NewGuid().ToString("N") = 32 characters (Digits and Letters only, no braces nor hyphens) outputs: 12345678123412341234123456789abc Guid.NewGuid().ToString("B") = 38 characters (Braces) outputs: {12345678-1234-1234-1234-123456789abc} Guid.NewGuid().ToString("P") = 38 characters (Parentheses) outputs: (12345678-1234-1234-1234-123456789abc) Guid.NewGuid().ToString("X") = 68 characters (Hexadecimal) outputs: {0x12345678,0x1234,0x1234,{0x12,0x34,0x12,0x34,0x56,0x78,0x9a,0xbc}}

36, GUID将只使用0-9A-F(十六进制!)

12345678 - the 1234-1234-1234-123456789012

在任何GUID中都是36个字符——它们的长度是恒定的。你可以在这里读到更多关于guid的复杂之处。

如果您想存储大括号，还需要两个长度。

注意:36是字符串长度，中间有破折号。它们实际上是16字节的数字。