这种情况我之前在做批量数据查询时也碰到过，结合SQLite的特性和硬件IO的底层限制，主要有这几个核心原因：

1. 硬盘IO并发能力的天然瓶颈 #

你单文件查询能跑到200MB/s，说明硬盘的连续读取性能很强，但硬盘的随机/多队列并发IO能力往往远低于连续读取：

• 如果是机械硬盘（HDD），磁头频繁在8个文件的不同存储位置间寻道，会把大量时间浪费在物理移动上，而不是实际读取数据。HDD的随机IOPS通常只有几百，多文件并发时性能暴跌几乎是必然的；
• 就算是固态硬盘（SSD），消费级SSD的并发读写带宽也会比单队列连续读低很多——SSD的闪存颗粒和控制器有队列深度限制，当同时处理多个文件的IO请求时，控制器的调度开销会大幅增加，整体带宽被分摊。

2. WAL模式的隐性开销（即使是只读查询） #

虽然你设置了journal_mode = wal和synchronous = off，但WAL模式在多文件并发场景下还是会带来额外开销：

• 每个启用WAL的SQLite数据库都会对应一个共享内存区域和WAL文件，操作系统需要维护更多的内存映射、文件句柄和锁资源，这会增加内核的调度负担；
• 哪怕是只读查询，SQLite打开WAL模式的数据库时，都会先检查WAL文件的完整性和日志序列，这个操作在8个线程同时执行时，会累积出可观的IO和CPU开销。

3. 单线程模式的认知误区 #

你把每个SQLite设置为single-thread模式，这个配置只是让SQLite内部不启用线程安全机制，但这解决不了操作系统层面的资源竞争：

• 8个线程同时向硬盘发起IO请求，操作系统的IO调度器必须把这些请求排队处理。当请求数量超过硬盘的并发处理上限时，每个线程都会进入等待队列，实际能分到的带宽自然被压缩到很低；
• 单线程模式下SQLite不会做跨连接的优化，但你的场景是多文件多线程，核心瓶颈根本不在SQLite内部锁，而是底层IO。

4. 文件缓存的利用率下降 #

单文件查询时，操作系统的页缓存可以高效地把读取的数据存起来，后续请求直接从内存读取，速度拉满。但同时读取8个大文件时，缓存可能无法容纳所有需要的数据，导致大量请求不得不直接访问硬盘，这也会拖慢整体速度。

可以尝试的优化方向 #

• 如果用的是HDD，尽量减少并发文件数，或者把多个SQLite文件合并成一个（用不同表或分区），重新利用连续读取的优势；
• 换成企业级SSD，这类硬盘的控制器和闪存颗粒专门优化了并发IO性能，多文件场景下的表现会好很多；
• 只读场景下可以把journal_mode改成delete，去掉WAL相关的额外开销；
• 查询前预热数据：用PRAGMA cache_size = <大数值>调大SQLite的内存缓存，或者用简单的命令把文件提前加载到系统缓存里。

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