没有 ROWID 和整数主键的 SQLite

Question

1. 是否应该使用“WITHOUT ROWID”创建具有 INTEGER PRIMARY KEY 的新表？

文档似乎表明：

在一个优雅的系统中，即使没有WITHOUT ROWID关键字，所有表都将表现为WITHOUT ROWID表。

https://www.sqlite.org/withoutrowid.html

ROWID 别名上也存在空间开销 SQLite 中的整数主键与 rowid

2. 这篇文章似乎表明

   WITHOUT ROWID

   是对旧数据库的兼容性。

您通常不应在任何新项目中使用

WITHOUT ROWID

表。引入此选项是为了支持向后兼容旧数据库。

https://chumaky.team/blog/sqlite-primary-key-explained

Answer 1

实际上，WITHOUT ROWID 的唯一好处是主键不是整数类型。此时 rowid 列/索引不存在。但是，如果您有...INTEGER PRIMARY KEY ...没有ROWID，那么您实际上正在有效地使用rowid列/索引，但有细微的差别。

• 列的值不能由 SQLite 内部生成，必须提供一个值。
• null 值将导致 NOT NULL 冲突，而不是由 SQLite 内部生成的值。
• 所以值必须被管理，而对于 rowid 表，值可以留待生成。
  • 在某些情况下，无论出于何种原因，都使用了可能的最高值（9223372036854775807）。
    • 对于一个rowid表SQLite（只要没有使用AUTOINCRMENT），会尝试找到一个未使用的值（永远不知道这样的值不被分配）
    • 对于WITHOUT ROWID表，你会做什么？
    • 显然是一种罕见的情况（但很容易证明）

实际上，WITHOUT ROWID 表适用于具有非整数或复合类型主键的表。在这种情况下，rowid 列和索引可能没有好处，只会浪费空间并消耗管理 rowid 及其索引的额外资源。

• 但是，应该注意的是，SQLite 的设计有利于 rowid 及其索引，处理速度更快（根据文档，速度最高可达两倍）。

• 此外，对于 64 位有符号整数，整数是存储、检索和操作最多 8 个字节的最小且最有效的值（参见上文，尽管有符号，但也可以有负值）。文本/字符串值很快就会超过 8 个字节。

我认为以下是官方文档中最相关的观点/声明之一：-

因此，在某些情况下，WITHOUT ROWID 表可以使用大约一半的磁盘空间，并且运行速度几乎是两倍。当然，在现实世界的模式中，通常会有二级索引和/或UNIQUE约束，并且情况更加复杂。但即便如此，在具有非整数或复合主键的表上使用WITHOUT ROWID通常可以带来空间和性能优势。

• 注意 some、can、often .... 而不是 all、will、always .... 并且 最重要的是 它以 .... 结尾，具有非整数或复合 PRIMARY钥匙.