挂载AWS EFS的100GB只读SQLite文件性能优化：SQLite配置建议及方案评估

针对你这种只读大SQLite文件在EFS上的性能问题，确实有几个SQLite配置可以针对性优化，先给你拆解清楚哪些有用、哪些没用，再聊聊其他可能的思路：

一、对只读场景有效的SQLite配置 #

1. 增大页面大小（PRAGMA page_size = 65536;） #

你提到的这个思路完全正确。EFS的随机IO延迟高，更大的页面（比如64KB，是默认4KB的16倍）意味着每次IO能读取更多数据，直接减少请求次数。注意这个参数必须在数据库创建时设置，如果是已有的数据库，需要执行VACUUM命令让新页面大小生效——因为你是只读场景，建议在本地先完成VACUUM操作，再把处理好的文件放到EFS上，避免在EFS上做耗时的磁盘操作。

2. 启用内存映射（PRAGMA mmap_size = 107374182400;） #

这是针对大文件只读场景的核心优化。把整个100GB的SQLite文件映射到内存中，系统会自动缓存常用的数据页，避免频繁从EFS读取。设置mmap_size为文件的实际大小（100GB=107374182400字节），这样SQLite可以直接通过内存访问文件内容，大幅降低随机访问的延迟。

3. 增大缓存大小（PRAGMA cache_size = <数值>） #

调整SQLite的内存缓存，让它把更多常用数据留在内存里。数值按页面数计算，比如你用64KB页面，设置cache_size = 1000000就相当于64GB缓存（根据你的机器内存情况调整，别超过可用内存）。重复查询时，大部分数据都能从缓存命中，不用再碰EFS。

4. 临时存储放内存（PRAGMA temp_store = MEMORY;） #

即使是只读查询，复杂的SQL（比如排序、分组、多表JOIN）可能会生成临时表。把临时存储设置为内存，避免在EFS上创建临时文件——EFS的写性能本来就差，这样能避免额外的性能损耗。

5. 设置只读模式（PRAGMA query_only = 1;） #

开启这个参数后，SQLite会跳过所有写相关的检查和操作（比如日志、锁机制），不仅能防止误写，还能减少一些不必要的开销，对只读场景有小幅性能提升。

二、对你的场景没用的配置 #

你提到的PRAGMA SYNCHRONOUS = OFF;和PRAGMA journal_mode = PERSIST;在只读模式下完全没用。这两个参数都是针对写操作的：SYNCHRONOUS控制写磁盘的同步策略，journal_mode控制事务日志的模式——而你的场景根本不会写数据库，所以设置它们不会带来任何性能提升，完全可以忽略。

三、除了SQLite配置，还有这些优化方向 #

1. EFS本身的配置调整：如果用的是AWS EFS，切换到「最大IO」性能模式（适合大文件随机访问），并设置「预置吞吐量」避免突发性能限制，这能从存储层面提升基础性能。
2. 预缓存预热：容器启动前，先执行dd if=/path/to/your/db.sqlite of=/dev/null bs=64k读取整个文件，让操作系统把文件内容缓存到内存里。这样容器启动后，第一次查询的延迟会大幅降低。
3. 优化现有复制方案：如果最终还是要用到本地存储的方案，可以试试用rsync做增量同步（如果SQLite文件更新不频繁的话），或者提前把文件预存在机器的本地SSD上，容器直接挂载使用，省去每次启动都复制700秒的时间。

总结 #

如果通过上述SQLite配置+EFS调整，能把启动和查询性能降到可接受的范围，那完全可以不用复制到本地；但如果性能还是达不到要求，你当前的本地复制方案确实是最优选择——毕竟本地存储的随机IO性能是EFS无法比拟的。

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