sql - NULL或NOT到NULL-对性能的影响

Question

因此，我正在导入大型JSON数据并将其转换为SQLite服务器。我正在使用事务进行插入，并且已经尝试使用NULL表或不使用NULL来检查性能差异。

当我在SQLite中创建表时，如下所示：

CREATE TABLE comments(
    id TEXT, 
    author TEXT, 
    body TEXT, 
    score INTEGER, 
    created_utc TEXT
);

导入时间确实很慢，并且在表中搜索（例如，在author ='blabla'的注释中选择*）也很慢。

当改为使用具有指定NULL或NOT NULL约束的表时，导入时间和搜索时间快得多（从2000秒到600秒）。

CREATE TABLE comments(
    id TEXT PRIMARY KEY, 
    author TEXT NOT NULL, 
    body TEXT NULL, 
    score INTEGER NULL, 
    created_utc TEXT NULL
);

有谁知道为什么使用NULL或NOT NULL时会发生这种性能变化？

Answer 1

根据我的评论，添加PRIMARY KEY可能是改善搜索效果的主要因素。尽管它可能会对插入产生负面影响，因为必须维护该索引。

编码NULL没什么区别，因为它只是将NOT NULL标志留为0，因此可以忽略。

编码NOT NULL可能会由于满足约束而导致插入次数减少，从而导致性能提高。

关于PRIMARY INDEX，将其编码为INTEGER PRIMARY KEY或INTEGER PRIMARY KEY AUTOINCREMENT以外的任何其他内容将导致创建后续索引。

也就是说，如果未使用WITHOUT ROWID定义表，则SQLite将使用通常不可见的列rowid创建“ REAL”主索引。这唯一地标识一行。 （尝试SELECT rowid FROM comments）

这样，在两种情况下，都存在一个基于行标识的索引。出于所有目的和目的，这将是插入行的顺序。

在第二种情况下，将有2个索引，即基于rowid的“ REAL”主索引和基于id列的已定义主索引。由于需要维护第二个索引，因此对插入内容会有一些影响。

因此，假设您在id列中搜索id x，在第一个表中它将相对较慢，因为它必须根据rowid顺序进行搜索，这就是它的全部。但是，根据id添加索引并进行搜索将是有利的，因为该索引（在2个可用索引中）是搜索可能基于的索引。

注意，上面是一个非常简单的概述，它没有考虑可能引起关注的The SQLite Query Planner。 ANALYZE statement可能也很有趣。