我注意到一些奇怪的东西，我不太确定该怎么做。下面的结果集基本上是我的应用程序写入其日志消息的表上的SQL Select语句的输出。我已经编辑了敏感材料，如网站和任务详细信息，并为您提供了字段数据类型而不是字段名，除了Firebird表中内置的RDB$DB_KEY。 我希望您关注的是我列出的行的顺序，尽管在我的SQL中使用按RDB $ DB_KEY订购。
Timestamp Field Varchar Field RDB$DB_KEY
======================== ====================== =================
19.12.2013, 10:40:40.000 Site_BC DB_2 connected 00000083:00000100
19.12.2013, 10:40:40.000 Site_BC DB_1 connected 00000083:000000fc
19.12.2013, 10:40:40.000 DB_1 tasks completed 00000083:000000fd
19.12.2013, 10:40:40.000 Site_A DB_2 connected 00000083:000000fe
现在，我可以发誓0在ASCII表中1之前，所以行的顺序（据说按RDB $ DB_KEY字段中的值按升序排序）没有对我来说似乎是对的。
我做了一些基础研究，显然这个RDB $ DB_KEY字段是一个字节数组（虽然我不确定）。我已经尝试将其作为varchar和char进行投射，但似乎Firebird Cast不支持从此数据类型转换。
有人可以帮我把这些行正确排序吗？我知道我可以添加另一列整数数据类型然后按那样排序，但我想我还是会问，以防万一有人知道如何通过这种混合祝福进行排序，称为RDB $ DB_KEY。
我正在使用Firebird 2.5版。
答案 0 :(得分：3)
您的选择中的RDB$DB_KEY输出只是格式化，以便在客户端上显示。它不是真正的密钥（！）。实际的RDB$DB_KEY是（对于表格）一个8字节的数组（或64位数字）。
现在关于排序，我不是100％确定确切的实现，但是RDB $ DB_KEY是big-endian，或者这个演示文稿是big-endian）。在big-endian中0x0100出现在0x00fc之前（在小端，它将是0x0001和0xfc00）。
但正如我在评论中已经指出的那样，按RDB$DB_KEY排序几乎没有意义。 RDB$DB_KEY表示记录的物理位置的“快照”，该记录仅在事务持续时间内有效（简化）。多个记录的RDB$DB_KEY的顺序通常不会反映插入顺序（如果是这样，在备份和恢复后该顺序可能会有所不同），而只是存储的相对位置（对于当前可见的顺序）记录版）。
答案 1 :(得分：0)
很遗憾没有其他人回复，你必须选择“这是你的问题”答案。
order by cast(rdb$db_key as blob)
我可能错了，但我怀疑FB在默认情况下排序db_key时只使用第一个字节。