我在使用Apache IoTDB 2.0.8的表格模型来分页查看结果。部分设备尚未上报温度，结果随后通过分页偏移进行消费。我需要知道仅按温度排序（ORDER BY temperature）是否能为温度为 NULL 的行提供一个稳定的顺序。

模式和测试数据：

CREATE TABLE inspection (device_id STRING TAG, temperature DOUBLE FIELD, humidity DOUBLE FIELD);

INSERT INTO inspection(`time`, device_id, temperature, humidity)
VALUES (1000, 'A', 80.0, 30.0);

INSERT INTO inspection(`time`, device_id, temperature, humidity)
VALUES (2000, 'B', `null`, 35.0);

INSERT INTO inspection(`time`, device_id, temperature, humidity)
VALUES (3000, 'C', 85.0, `null`);

INSERT INTO inspection(`time`, device_id, temperature, humidity)
VALUES (4000, 'D', `null`, 33.0);

我使用的SQL：仅按温度排序：

SELECT `time`, device_id, temperature
FROM inspection
ORDER BY temperature;

运行结果：

我已经尝试过的方法：添加显式 NULL 放置并引入一个平局打破条件：

SELECT `time`, device_id, temperature
FROM inspection
ORDER BY temperature NULLS FIRST, `time` DESC;

结果：

我的问题：

在IoTDB表格模型中，当多行具有相同的ORDER BY值时，特别是 NULL，在不添加二级排序键（例如 time 或 设备ID）的情况下，它们的相对顺序是否未被指定？

解决方案

我不能就Apache IOTDB具体情况发表评论。但就关系型数据库而言：否。 它不是确定性的。理论上IOTDB可能把这作为实现细节来保证，但我不会指望它会这么做。

有些数据库甚至可能——尽管在实践中较少见*——在同一台服务器对同一数据集执行同一查询时，结果会随时而变。这意味着你一次看到某种排序并不保证以后再看到同样的排序……但“在实践中较少见”的细节很重要，因为这意味着在测试期间你很可能会多次看到该排序，从而对未来会发生的情况产生错误的预期。

如果需要保持一致的排序，你需要再添加一列来打破平局。

• 实际上，排序往往（但再次强调：并无保证！）遵循数据库内存中已可用记录的顺序，通常是主键顺序，但如果存在覆盖索引用于查询，数据库可能会使用另一种索引。JOINs也可能改变用于确定排序的索引。如果数据库需要从存储加载行，它往往会使用页序来排序。但也有例外！我知道至少有一种数据库可以在进行中的另一个查询的基础上工作，利用该查询对行的现有读取，先返回本查询的行，然后在第一个查询结束后再补齐剩余的行（这通常被称为“旋转木马扫描”）。