嗨，这个问题其实是SQLite新手常遇到的误区——它并不是直接把单条数据写到磁盘上，而是有一套基于数据页的存储机制，再加上必要的事务保障设计，才导致了这样的结果。咱们一步步拆解：

• SQLite的核心：基于数据页存储
  SQLite把整个数据库分成固定大小的「数据页」，默认大小是4KB（你可以用PRAGMA page_size;命令查看当前数据库的页大小）。哪怕你的数据只有几个字节，SQLite也得把整个数据页写入磁盘。但4KB远不到48KB，这就涉及到其他额外开销了。

• 首次创建数据库的初始化开销
  当你第一次创建HKDevice表并插入数据时，SQLite不只是存储你的那一行数据：

  • 它会自动创建系统表（比如sqlite_master，用来记录所有数据库对象的元数据），这些表本身就需要占用数据页；
  • 为了避免频繁调整文件大小，SQLite会预分配一批数据页，第一次初始化时可能会分配多个4KB页，加起来就会有不少的写入量。

• 事务日志的磁盘写入
  为了保证操作的原子性（比如插入失败时能安全回滚），SQLite会先写「事务日志」：不管是默认的WAL（写前日志）还是传统的回滚日志，这些日志文件都会先被写入磁盘——哪怕事务提交后日志会被清理，磁盘已经记录了这些写入操作。这部分的开销也会算进总写入量里。

• 第二次插入的相似写入量
  第二次插入也有差不多的写入量很正常：第一次插入已经占用了部分数据页，第二次插入可能需要更新现有数据页（或者分配新页），再加上事务日志的固定开销。等你插入更多数据，把预分配的页填满后，后续的插入就会只占用少量增量空间了——比如每插入几十行才需要写一个新页。

如果你想验证这个逻辑，可以试试一次性插入1000行数据，你会发现总写入量远不是1000×48KB，而是更接近实际数据大小加上固定的页和日志开销。

内容的提问来源于stack exchange，提问作者Karim