Question

我们有一个非常简单的数据库：

 CREATE TABLE IF NOT EXISTS tblIndex(
     frame_type  INT, 
     pts  VARCHAR(5),
     ts_start  INT primary key,
     ts_end  INT)

应用场景是：

每隔一个用户将插入2~50条记录，这些记录的ts_start字段总是在增加。 8小时后，最多有1_800_000条记录。通过将同步模式设置为关闭，到目前为止性能似乎正常。由于每条记录的数据只有16个字节，即使插入速度不是太快，我们也可能会使用一些缓冲区。
8个小时后，用户会告诉我通过告诉上限ts_start删除最旧的数据，所以我会这样做

DELETE FROM tblIndex WHERE ts_start < upper_bound_ts_start.

从1_800_000中删除90_000（这是半小时的记录）现在需要17秒。比预期更长的垃圾。有什么方法可以减少这个？我们不关心记录是否立即同步到硬盘。我们正在考虑启动一个单独的线程来执行删除操作，以使此调用为异步。我不确定的事情是（长时间）删除是否会影响插入性能，如果它们共享相同的连接？或者我应该使用单独的连接进行插入和删除？但是这样，他们是否需要在应用程序级别同步？
搜索。 SELECT ts_start FROM tblIndex WHERE ts_start BETWEEN ? AND ? - 由于ts_start是主键，所以现在我们的需求可以满足性能要求。我想我应该使用一个单独的连接进行搜索，对吗？

SQLite的配置：

hard disk database (usb interface)
cache size is 2000
page size is 1024
sync mode is 0 (off)
journal_mode mode is truncate

感谢您提出改进删除效果或整体设计的建议。

编辑：350M MIPS CPU，而不是特定于此应用程序的太多内存（<2M）。

Answer 1

由于数据是暂时的 - 而且很小 - 为什么要使用数据库？

对于简单的平面文件目录，你会更开心。

您的网络查询可以简单地读取相关的文件集并返回所需的结果。 1_800_000个16字节的记录只是28Mb的文件数据。您可以将整个内容读入内存，在内存中进行处理，并显示结果。

单独的流程可以在午夜每天删除一次旧文件。

第三个进程每秒可以将2-50个16字节的记录附加到工作文件中。

写入并刷新，以便在每个I / O之后文件正确并完整。如果您的读者优雅地处理不完整的最后记录，您甚至不需要锁定。
根据时间为每个文件命名序列号。例如，您可以将系统时间（以秒为单位）除以4 * 60 * 60并截断答案。这是一个每4小时推进一次的序列号，创建一个新文件。 8小时的数据是其中3个文件（2个以前的4小时文件，加上当前的工作文件。）

Answer 2

每半小时有一个sqlite数据库怎么样？换句话说，每半小时启动一个新的数据库文件，然后删除旧的。