在HSQLDB数据库中存储UUID

Question

我希望将使用 java.util.UUID 创建的 UUID 存储在 HSQLDB 数据库中。

显而易见的选择是将它们简单地存储为字符串（在代码中它们可能只是被视为字符串），即 varchar(36)。

考虑到数据库大小和查询速度等问题，我还应该考虑哪些其他选项（由于涉及的数据量，这些都不是一个大问题，但我至少想考虑它们）

Answer 1

HSQLDB 有一个内置的 UUID 类型。使用它

CREATE TABLE t (
  id UUID PRIMARY KEY
);

Answer 2

您有几个选择：

• 将其存储为 VARCHAR(36)，正如您已经建议的那样。这将占用每个 UUID 36 字节（288 位）的存储空间，这还不包括开销。
• 将每个 UUID 存储在两个 BIGINT 列中，一列用于最低有效位，一列用于最高有效位；使用 UUID#getLeastSignificantBits() 和 UUID#getMostSignificantBits() 抓取每个部件并适当存放。这将占用每个 UUID 128 位的存储空间，这还不包括任何开销。
• 将每个 UUID 存储为 OBJECT；这将其存储为 UUID 类的二进制序列化版本。我不知道这占用了多少空间；我必须运行测试来查看 Java UUID 的默认序列化形式是什么。

每种方法的优点和缺点取决于您在应用程序中传递 UUID 的方式 - 如果您将它们作为字符串等效项传递，那么缺点是需要双倍的 VARCHAR(36) 存储容量这种方法可能更重要，因为不必在每次进行数据库查询或更新时都转换它们。如果您将它们作为本机 UUID 传递，那么 BIGINT 方法的开销可能相当低。

哦，很高兴您考虑速度和存储空间问题，但正如许多比我更好的人所说，考虑到您的应用程序将存储的数据量，您认识到这些可能不是至关重要的也很好和维护。一如既往，为了性能而进行的微优化只有在不这样做会导致不可接受的成本或性能的情况下才重要。否则，考虑到廉价的存储成本和数据库索引的能力，这两个问题——UUID 的存储空间以及在数据库中维护和查询它们所需的时间——的重要性相当低。容易多了。 :)

Answer 3

1. 我建议使用 char(36) 而不是 varchar(36)。不确定 hsqldb，但在许多 DBMS 中，char 速度要快一些。

2. 对于查找，如果 DBMS 很智能，那么您可以使用整数值来“更接近”您的 UUID。

例如，将 int 列以及 char(36) 添加到表中。当您插入表时，将 uuid.hashCode() 插入 int 列。那么你的搜索可以像这样

WHERE intCol = ? and uuid = ?

正如我所说，如果 hsqldb 像 mysql 或 sql server 一样智能，它会通过 intCol 缩小搜索范围，然后仅通过 uuid 比较最多几个值。我们使用这个技巧通过字符串搜索百万+记录表，它本质上与整数查找一样快。

Answer 4

使用 BINARY(16) 是另一种可能性。比字符类型更少的存储空间。按照上面的建议使用 CREATE TYPE UUID .. 或 CREATE DOMAIN UUID .. 。

Answer 5

我认为最简单的事情就是创建您自己的域，从而创建您自己的 UUID“类型”（不是真正的类型，但几乎是）。

您还应该考虑这个问题的答案（特别是如果您打算使用它而不是“普通”主键）

HSQLDB 中的 INT、BIGINT 或 UUID/GUID？（已被社区删除...）

HSQLDB：域创建和操作