SQL Server FLOAT(53)列存储超2^24整数的异常现象及疑问

你混淆了单精度和双精度浮点数的精度限制。SQL Server中FLOAT(53)对应IEEE 754双精度浮点数，这类浮点数的尾数包含52位显式存储位+1位隐含位，总共53位有效精度——这意味着所有小于等于2^53（约9×10¹⁵）的整数都能被精确表示。16777217（即2²⁴+1）远小于这个阈值，所以完全可以被双精度浮点数精准存储和区分。

你提到的"16777216和16777217的二进制浮点表示相同"，是单精度浮点数（对应SQL Server的FLOAT(24)及以下）的特性。单精度仅提供24位尾数精度，超过2²⁴的整数无法精确区分相邻值，但双精度不存在这个限制。

验证SQL Server的存储行为 #

可以通过查看浮点数的二进制存储来确认：

SELECT 
    COL,
    sys.fn_varbintohexstr(CAST(COL AS VARBINARY(8))) AS BinaryRepresentation
FROM F_ING_FLOATS;

执行后会得到两个不同的二进制值：

• 16777216的双精度二进制：0x4170000000000000
• 16777217的双精度二进制：0x4170000000000001
  这证明SQL Server确实是按标准双精度格式存储数据，没有偏离定义。

Parquet中精度丢失的原因 #

Parquet文件中出现的精度丢失，大概率是导出过程中的类型转换错误：

• 可能是导出工具将SQL Server的FLOAT(53)（双精度）错误映射为Parquet的FLOAT32（单精度）类型，导致数据被截断为单精度，从而出现16777217被转成16777216的情况。
• 也可能是导出流程中存在精度截断逻辑，强制将双精度值转换为单精度存储。

总结 #

• SQL Server的FLOAT(53)完全符合IEEE 754双精度定义，能精确存储2^53以内的所有整数，所以你看到的能区分16777216和16777217的结果是正常的。
• 你的初始误解源于将单精度浮点数的精度限制错误套用到了双精度上。
• Parquet中的异常是导出环节的问题，与SQL Server的存储无关。

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