When working with large 64-bit integer identifiers (such as order IDs, sequence numbers, or Snowflake IDs) in time-series databases like Apache IoTDB, you might occasionally encounter perplexing query results. A classic example is querying for an ID like 9007199254740993.0 and unexpectedly receiving a record containing 9007199254740992 instead of an exact match or an empty result.

This behavior is not a bug in Apache IoTDB, but rather the result of two fundamental computing mechanisms working together: IEEE 754 double-precision floating-point limits and SQL implicit type coercion.

1. The Root Cause: IEEE 754 Floating-Point Precision

In SQL syntax, appending a decimal point (such as .0) turns a numeric literal into a floating-point number (typically a 64-bit DOUBLE). In standard IEEE 754 binary floating-point representation, 64-bit floats allocate 53 bits to the significand (mantissa).

Because of this 53-bit limit, the maximum consecutive integer that can be safely and accurately represented without losing precision is: