sql-server - 如果 SQL Server USER_NAME() 是系统名，为什么它返回 NVARCHAR(256)？

Question

我正在处理一个列，我想保存 SQL Server 2008 R2 中的 USER_NAME() 函数的值。在 BOL ，该函数被记录为返回类型为 NVARCHAR(256)。

但是，在其中一个示例中，他们这样做:

SELECT name FROM sysusers WHERE name = USER_NAME(1)

并且 sysusers.name 列的类型为 sysname ，(据我所知)实际上是一个 NVARCHAR(128) NOT NULL。 CURRENT_USER 的文档进一步证实了这种不一致。 ，它表示“此函数等效于 USER_NAME()”，但指示其类型为 sysname (当然，接下来还有一个使用 CURRENT_USER 的示例)作为 VARCHAR(30) 列的默认值...)

什么给了？ BOL 对 USER_NAME() 类型的判断是否错误？使用 NVARCHAR(128) 安全吗？

Answer 1

好吧，让我们看一下:

SELECT name, system_type_id, user_type_id, max_length
  FROM sys.types WHERE name IN (N'sysname', N'nvarchar');

结果:

name      system_type_id  user_type_id  max_length
--------  --------------  ------------  ----------
nvarchar  231             231           8000
sysname   231             256           256

sysname 只是 nvarchar 的别名类型，其定义的字符数为 128(而不是 256) )。 sys.types 表示 256 的原因是 nvarchar 每个字符有 2 个字节 - 因此 128 个字符 x 2 个字节 = 256 个字节。他们所说的“长度”与我们通常所说的“长度”含义不同。

对于 BOL 所说的“为什么”，没有答案 - 在线图书只是错误的，仅此而已。证明:

SELECT x = USER_NAME() INTO #foo;
EXEC tempdb..sp_help '#foo';

部分结果:

Column_name  Type      Length
-----------  --------  ------
x            nvarchar  256

-----------------------^^^
---- again, this is 128 characters

是的，使用 NVARCHAR(128) 应该是安全的，但是为了以防万一，您是否需要花费任何额外费用来匹配文档？也不要再查看像 sysusers 这样已弃用的系统表，以获取有关数据类型选择和证实文档的指导。虽然在本例中 sys.database_principals 和 sys.server_principals 也使用 sysname，但它们是检查 SQL Server 如何工作的更可靠的地方今天，除非您真的在研究 13 多年前 SQL Server 的工作原理。