为什么SQLite插入成本是线性的？

我假设插入的时间成本是记录数的对数。但我在SQLite 3.22中的测试似乎表明它是线性的。注：X/Y均为对数比例

sizek列是我在每次测试中插入的行数。它的单位是K。我做了3次测试。日志和同步已关闭。锁定模式是独占的。所有操作都包含在一个事务中

时间1

时间2

时间3

所有3个测试用例都有类似的成本。它们似乎是线性的。 我还认为案例3可以更快，因为更新不需要重新平衡树或添加新记录。但是第三种情况有点慢

---

预期结果如何？也许我的输入数据太小，无法看到日志的复杂性？

SQLite优化了表末尾的插入。btree.c中的sqlite3BtreeInsert具有：

若要降低运行时间，请尝试按随机顺序插入行，或者至少先插入一个非常大的值

---

无论如何，运行时主要由磁盘I/O控制，非叶页最有可能被缓存。使用更多事务，以便所有页面都需要刷新到磁盘，或者使用内存中的数据库。

当我意识到B树有一个中点头，而不是最小头时，我删除了我的答案，哇！这使得我关于插入时间的大部分断言都是错误的。为什么要测试这样一个旧版本的SQLite？另外，一个对数比例的曲线图（看起来是线性的）实际上代表了一个对数分布。@MarkBenningfield X和Y都是对数比例的。所以这条线意味着线性。我使用的是最新的3.22版本，实际上，修复了我的问题。你能为这三个测试发布你的C代码吗？插入有序数据时，拆分/重新平衡发生在非叶节点上。插入随机数据时，拆分/重新平衡更多地发生在叶节点上。因为磁盘IO占主导地位，所以随机数据更可能显示日志复杂性。这就是它的工作原理吗？首先，测量它的实际行为。

create table t1 (id primary key, name text);
create index nameIdx on t1(name)
// for i = [1:<size>]
//   insert into t1 values(i, "foo"i)
create table t2 (id primary key, value int);
// for i = [1:<size>]
//   insert into t2 values(i, i)

create table t1 (id primary key, name text);
// for i = [1:<size>]
//   insert into t1 values(i, "foo"i)
create index nameIdx on t1(name)
create table t2 (id primary key, value int);
// for i = [1:<size>]
//   insert into t2 values(i, i)

create table t1 (id primary key, name text, value int);
// for i = [1:<size>]
//   insert into t1 values(i, "foo"i, 0)
create index nameIdx on t1(name)
// for i = [1:<size>]
//    update t1 set value=0 where id=<i>

/* If the cursor is currently on the last row and we are appending a
** new row onto the end, set the "loc" to avoid an unnecessary
** btreeMoveto() call */