SQL Server中CONVERT转bigint为varbinary结果与计算器十六进制不符及MAC存储疑问

• SQL Server 中 CONVERT(VARBINARY, 整数类型值) 的转换逻辑，是直接读取整数在内存中的原始字节布局，采用小端序（低位字节存储在内存低地址，也就是输出的二进制字符串最靠前的位置） 规则输出，和系统计算器默认输出的大端序十六进制顺序完全相反，不存在一致性基础。
• 当转换的数值超出int范围（比如你用到的894811944210），会被自动识别为bigint类型（8字节长度），此时指定VARBINARY(6)的截取规则是「从内存低地址（也就是小端存储的起始位置）取前6字节」，不会自动在高有效字节侧补零凑成目标长度的大端格式，最终结果自然和你预期的计算器输出对不上。

MAC地址在网络、系统层面的标准存储格式是6字节大端序二进制，和SQL Server默认的小端整数转二进制逻辑天然不兼容，直接用数值转二进制的方式永远得不到正确结果，需要按以下流程操作：

• 先将MAC对应的十进制值转换为12位长度的补零十六进制字符串（比如894811944210对应十六进制为D056F2B512，前面补0凑成12位得到00D056F2B512）
• 通过带格式参数的字符串转换得到标准二进制值，执行：
  SELECT CONVERT(VARBINARY(6), '00D056F2B512', 1)
  第三个参数1的作用是告知SQL Server输入字符串为十六进制语义，直接按字符顺序将每两位字符映射为一个字节，输出结果就是0x00D056F2B512，和计算器计算结果完全一致。
• 如果你一定要从十进制数值触发转换，需要先通过字符串函数把十进制转为12位补零的十六进制字符串，再走上面的字符串转换流程，不能直接把数值入参传给CONVERT转二进制。

• MAC地址固定为6字节长度，无需使用VARBINARY(250)这类弹性长度类型，直接使用BINARY(6)固定长度列存储即可，既节省存储空间，也能避免长度异常的脏数据。
• 后续查询展示时，可通过sys.fn_varbintohexstr函数将二进制值转回标准十六进制字符串，按需拼接冒号即可得到00:D0:56:F2:B5:12这类常用的MAC展示格式。

内容的提问来源于stack exchange，提问作者Vijay