SQLite 默认未开启 WAL ，这会显著限制并发性能。 PlanTodo 是一个计划管理软件，最近我为它的同步服务编写了性能测试，经过实测，仅开启 WAL 就让同步服务的吞吐量便提升至原来的 3 倍， 其实关于 SQLite 性能优化的文章早有珠玉在前，比如 Optimal SQLite settings for Django 和 Optimizing SQLite for servers ，所以本篇文章并没有独创性，只是为了让更多人了解 SQLite 的 性能 以及分享一个真实的性能 测试用例 。 PlanTodo 同步服务性能测试 性能测试分为三个： oo_upload (one user, one device for a user, only upload) ，就是一个用户一台设备仅上传 oo_download 就是仅下载 oo_cross 是上传和下载交错进行 oo_upload 和 oo_download 是为了查看上传和下载场景下的极限性能，是为了将来专门优化时用来参考的。而 oo_cross 则较为贴近真实使用场景：用户的某个设备上传几个更新，另一个设备被触发下载；因此可以拿它计算服务器能承受的用户量。 如果你不想看下面具体的测试数据，这里简单展示了吞吐量的变化： oo_upload ，18027 -> 61682 ，是原来的 3.42 倍 oo_download ，17082 -> 49635 ，是原来的 2.90 倍 oo_cross ，17085 -> 44203 ，是原来的 2.58 倍 一般查询是比写入要快的，因此下载应该比上传快，但 PlanTodo 的同步服务却反了过来，说明有很大的优化空间。 下面是开启 WAL 前的测试数据： + just -f services/sync/justfile headless_oo_upload --less-output ============================================================ Performance Summary for test_oo_upload ============================================================ Requests : 18,027 Failures : 0 Failure Rate : 0.00% Average RT : 78.14 ms P50 : 78 ms P95 : 110 ms P99 : 130 ms Max : 272.81 ms Endpoints ------------------------------------------------------------ POST /v1/sync/delta Requests=18,011 Avg=78.1ms P95=110ms P99=130ms Max=272.8ms POST /v1/clients Requests=8 Avg=76.2ms P95=110ms P99=110ms Max=109.9ms GET /v1/sync/full Requests=8 Avg=57.2ms P95=120ms P99=120ms Max=120.3ms + just -f services/sync/justfile headless_oo_download --less-output ============================================================ Performance Summary for test_oo_download ============================================================ Requests : 17,082 Failures : 0 Failure Rate : 0.00% Average RT : 82.63 ms P50 : 82 ms P95 : 110 ms P99 : 130 ms Max : 370.33 ms Endpoints ------------------------------------------------------------ POST /v1/sync/delta Requests=16 Avg=172.6ms P95=370ms P99=370ms Max=370.3ms GET /v1/sync/delta?cursor=1780662404990&limit=100 Requests=2,087 Avg=83.4ms P95=110ms P99=130ms Max=316.1ms GET /v1/sync/delta?cursor=1780662403978&limit=100 Requests=2,102 Avg=83.3ms P95=110ms P99=130ms Max=325.5ms + just -f services/sync/justfile headless_oo_cross --less-output ============================================================ Performance Summary for test_oo_cross ============================================================ Requests : 17,085 Failures : 0 Failure Rate : 0.00% Average RT : 83.05 ms P50 : 82 ms P95 : 120 ms P99 : 150 ms Max : 245.89 ms Endpoints ------------------------------------------------------------ GET /v1/sync/delta?cursor=1780662760888&limit=100 Requests=1 Avg=245.9ms P95=250ms P99=250ms Max=245.9ms GET /v1/sync/delta?cursor=1780662760900&limit=100 Requests=1 Avg=245.4ms P95=250ms P99=250ms Max=245.4ms GET /v1/sync/delta?cursor=1780662758760&limit=100 Requests=1 Avg=228.2ms P95=230ms P99=230ms Max=228.2ms 下面是 开启 WAL 之后 的测试数据： + just -f services/sync/justfile headless_oo_upload --less-output ============================================================ Performance Summary for test_oo_upload ============================================================ Requests : 61,682 Failures : 0 Failure Rate : 0.00% Average RT : 22.30 ms P50 : 22 ms P95 : 32 ms P99 : 41 ms Max : 74.82 ms Endpoints ------------------------------------------------------------ POST /v1/clients Requests=8 Avg=33.8ms P95=48ms P99=48ms Max=48.1ms POST /v1/sync/delta Requests=61,666 Avg=22.3ms P95=32ms P99=41ms Max=74.8ms GET /v1/sync/full Requests=8 Avg=20.7ms P95=32ms P99=32ms Max=32.5ms + just -f services/sync/justfile headless_oo_download --less-output ============================================================ Performance Summary for test_oo_download ============================================================ Requests : 49,635 Failures : 0 Failure Rate : 0.00% Average RT : 28.03 ms P50 : 28 ms P95 : 38 ms P99 : 46 ms Max : 305.64 ms Endpoints ------------------------------------------------------------ POST /v1/sync/delta Requests=16 Avg=127.0ms P95=310ms P99=310ms Max=305.6ms GET /v1/sync/delta?cursor=1780663066610&limit=100 Requests=6,109 Avg=28.4ms P95=38ms P99=46ms Max=246.0ms GET /v1/sync/delta?cursor=1780663068640&limit=100 Requests=6,064 Avg=28.3ms P95=38ms P99=46ms Max=95.8ms + just -f services/sync/justfile headless_oo_cross --less-output ============================================================ Performance Summary for test_oo_cross ============================================================ Requests : 44,203 Failures : 0 Failure Rate : 0.00% Average RT : 31.80 ms P50 : 28 ms P95 : 45 ms P99 : 150 ms Max : 477.37 ms Endpoints ------------------------------------------------------------ GET /v1/sync/delta?cursor=1780663421960&limit=100 Requests=1 Avg=477.4ms P95=480ms P99=480ms Max=477.4ms GET /v1/sync/delta?cursor=1780663421963&limit=100 Requests=1 Avg=475.9ms P95=480ms P99=480ms Max=475.9ms GET /v1/sync/delta?cursor=1780663421966&limit=100 Requests=1 Avg=475.4ms P95=480ms P99=480ms Max=475.4ms 每个测试只持续了 3 min ，因此数据量很小，在大数据量的情况下，性能可能会下降很多，这个会在将来补充。 在测试 oo_cross 里，3min 处理了 44203 个请求，也就是一秒 245 个。测试其实是不断在重复先上传再下载，而客户端也是上传下载成对出现，因此一秒能处理 122 （ 245 / 2 ）台设备的请求，即便因为多用户、多设备带来的其他压力，至少能稳定在一秒 100 个请求。 考虑到，真实使用下，平均要几分钟到十几分钟才会更新一次内容，取 10 分钟一次的话，一个同步服务极限下能支撑 100 x 60 x 10 ，6 万个设备正常使用。 如何开启 WAL 不管是什么 ORM ，开启的方式都是一样的，就是在连接数据库后，执行一次 PRAGMA journal_mode=WAL 。 开启了 WAL 后，在原本的 SQLite 数据库文件那里，会多出两个 .db-shm 、 .db-wal 的文件，可以以此判断是否成功开启。 SQLAlchemy from sqlalchemy import create_engine, event engine = create_engine( DATABASE_URL, echo=False, connect_args={ "timeout": 5, }, ) if engine.dialect.name == "sqlite": @event.listens_for(engine, "connect") def set_sqlite_pragma(dbapi_connection, _): cursor = dbapi_connection.cursor() # cursor.execute("PRAGMA foreign_keys=ON") cursor.execute("PRAGMA journal_mode=WAL") cursor.execute("PRAGMA synchronous=NORMAL") cursor.execute("PRAGMA temp_store=MEMORY") cursor.execute("PRAGMA cache_size=2000") cursor.execute("PRAGMA mmap_size=134217728") cursor.close() PlanTodo 的同步服务就是使用 FastAPI + SQLAlchemy 开发的。由于同步服务的特殊性，这里没有开启外键约束。 Django 在项目的 settings.py 文件里，添加 init_command： DATABASES = { "default": { "ENGINE": "django.db.backends.sqlite3", "NAME": BASE_DIR / "db.sqlite3", "OPTIONS": { "init_command": ( "PRAGMA foreign_keys = ON;" "PRAGMA journal_mode = WAL;" "PRAGMA synchronous = NORMAL;" "PRAGMA busy_timeout = 5000;" "PRAGMA temp_store = MEMORY;" "PRAGMA cache_size = 2000;" "PRAGMA mmap_size = 134217728;" ), }, } } drift 在数据库类的 migration get 方法里，在 beforeOpen 这个回调里增加执行命令： class PtdDatabase extends _$PtdDatabase { // 省略无关代码 @override MigrationStrategy get migration { return MigrationStrategy( beforeOpen: (details) async { // 在每次打开数据库，正式使用之前，执行的命令 await customStatement('PRAGMA journal_mode = WAL'); await customStatement('PRAGMA synchronous = NORMAL'); await customStatement('PRAGMA busy_timeout = 5000'); await customStatement('PRAGMA temp_store = MEMORY'); await customStatement('PRAGMA cache_size = -2000'); }, ); } } 原文链接： https://yanh.tech/2026/06/sqlite-performance-optimization/ 版权声明：本博客所有文章除特別声明外，均为 AhFei 原创，采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 技焉洲 (yanh.tech) 。
将复杂任务分解，逐步推进。 任务可继承父子计划的关系。 iOS 新上架： https://apps.apple.com/cn/app/plantodo-app/id6764485281 其他平台： https://plantodo.app/zh/
PlanTodo 是一个拥有强大计划系统的待办应用，免费，跨平台，支持多设备使用。全平台的下载链接可以到官网查看： https://plantodo.app/ 。 TestFlight 链接： https://testflight.apple.com/join/MeDAtFqP 。 这有个我准备的用例 https://plantodo.app/static/plantodo_cases.json ，下载后可以在应用设置里全量导入，快速了解功能。 与传统 Todo 应用不同，PlanTodo 将「任务」与「计划」明确分离： 任务：一次性待办事项 计划：可自动生成任务的规则系统 你可以像普通待办应用一样使用它，也可以利用强大的计划系统，自动安排长期事务。 支持常见循环规则： 每天 每周一、周五 每月 1 号 也支持更复杂的高级计划： 每月最后一个周六 跟随其他计划联动触发 在某个计划触发前第 3 天自动创建任务 适用于： 周期性工作安排 健身与学习计划 账单、维护、复盘提醒 长期项目管理 更多计划规则与功能，可在应用内查看。 指南： https://tutorial.plantodo.app/ 。
PlanTodo 是一个免费的待办应用，目前支持 Android 和 Windows ，在一个月以内会支持 iOS 、macOS 和 Linux ，实现全平台可用。 PlanTodo 的中文名是“放个计划”，从名称可见，其特色功能是“计划”。本应用将任务和计划明确区分开，任务是单次的，而计划拥有周期，条件满足时计划会被触发，然后生成相应的任务。 官网： https://plantodo.app/ 。 使用计划 定制自己的计划后，每天自动生成当天待办，进而规划一天的事情。 若想立马体验 PlanTodo 的功能，最好下载 用例 ，然后在客户端的设置页里导入，这样会加载一些精心准备的计划和进度，方便通过实际操作了解功能。 对于本应用，既可以重用计划，也可以轻用，甚至不用： 重用 就如动图所示，将一天中主要的事情都编写计划进行管理，这样每一天都可以有一个参考，促进形成习惯和保持健康生活的节奏。 轻用 就是只放周期比较特别的事情，防止忘记。比如每两个月换一次牙刷、每三周 Google Voice 保号、每三个月的周六对 NAS 进行冷备份、黑五前一周关注一些促销信息等。 不用 计划，只是将之作为一个朴素的任务安排应用。任务本身同样是本应用的重点功能，添加、编辑、删除、恢复、克隆等基本操作，开始时间、提醒、耗时、颜色标记等基本属性都有，其实计划只是节省了编写任务内容的工作。 任务安排不需要多复杂 花了半年时间开发的应用，称得上呕心沥血之作。从 4 年前读到 I tried every todo app and ended up with a .txt file — al3rez 这篇文章开始使用 纯文本 管理任务后，我就想着生成任务这一过程完全可以用程序实现，不用每天自己推理要做什么，于是就有了推理程序，有了 web ，最后有了 PlanTodo 。 个人的任务管理不需要那么花哨，能记下任务内容即可，加上耗时更好，如下是我之前记录任务的方式： 早上 07:07 起床，煮一壶水，吃早餐 30min ，安排今日工作 5min ，正式工作 2h30m ，中午吃饭 25min ，午觉 20min ，眺望(下午)，正式工作 1h30m ，正式工作 2h ，眺望，正式工作 1h30m ，做饭吃饭 1h ，吃维生素片，晚饭后出门溜达 10min ，慢跑 6min ，practice English https://www.youtube.com/watch?v=JKowwNf2CM0 20min ,晚上刷牙，看书 30min ，停止工作，上床休息，在 22:39 开始熄灯睡觉 每完成一件事就移走，如果不想干就删除，或者有临时新加的事情就打几个字，等一天的事情干完，就会形成一个流水账，然后放到日记里存着。一切都是纯文本的，好备份，平台无关、应用无关，想看的时候随便一个编辑器都能查看，Ctrl F 搜索关键词，其实对于个人完全够用。 PlanTodo 同样坚持这种 简洁 的理念，不引入多余的复杂度，如果不想使用本应用，只是想通过它生成每日任务，可以在生成任务后，打开右上角更多菜单，里面有今日摘要，点击后就会得到文字版的任务描述。 我的流水账。
PlanTodo 是一个免费的待办应用，目前支持 Android 和 Windows ，在一个月以内会支持 iOS 、macOS 和 Linux ，实现全平台可用。 PlanTodo 的中文名是“放个计划”，从名称可见，其特色功能是“计划”。本应用将任务和计划明确区分开，任务是单次的，而计划拥有周期，条件满足时计划会被触发，然后生成相应的任务。 官网： https://plantodo.app/ 。 使用计划 定制自己的计划后，每天自动生成当天待办，进而规划一天的事情。 若想立马体验 PlanTodo 的功能，最好下载 用例 ，然后在客户端的设置页里导入，这样会加载一些精心准备的计划和进度，方便通过实际操作了解功能。 对于本应用，既可以重用计划，也可以轻用，甚至不用： 重用 就如动图所示，将一天中主要的事情都编写计划进行管理，这样每一天都可以有一个参考，促进形成习惯和保持健康生活的节奏。 轻用 就是只放周期比较特别的事情，防止忘记。比如每两个月换一次牙刷、每三周 Google Voice 保号、每三个月的周六对 NAS 进行冷备份、黑五前一周关注一些促销信息等。 不用 计划，只是将之作为一个朴素的任务安排应用。任务本身同样是本应用的重点功能，添加、编辑、删除、恢复、克隆等基本操作，开始时间、提醒、耗时、颜色标记等基本属性都有，其实计划只是节省了编写任务内容的工作。 任务安排不需要多复杂 花了半年时间开发的应用，称得上呕心沥血之作。从 4 年前读到 I tried every todo app and ended up with a .txt file — al3rez 这篇文章开始使用 纯文本 管理任务后，我就想着生成任务这一过程完全可以用程序实现，不用每天自己推理要做什么，于是就有了推理程序，有了 web ，最后有了 PlanTodo 。 个人的任务管理不需要那么花哨，能记下任务内容即可，加上耗时更好，如下是我之前记录任务的方式： 早上 07:07 起床，煮一壶水，吃早餐 30min ，安排今日工作 5min ，正式工作 2h30m ，中午吃饭 25min ，午觉 20min ，眺望(下午)，正式工作 1h30m ，正式工作 2h ，眺望，正式工作 1h30m ，做饭吃饭 1h ，吃维生素片，晚饭后出门溜达 10min ，慢跑 6min ，practice English https://www.youtube.com/watch?v=JKowwNf2CM0 20min ,晚上刷牙，看书 30min ，停止工作，上床休息，在 22:39 开始熄灯睡觉 每完成一件事就移走，如果不想干就删除，或者有临时新加的事情就打几个字，等一天的事情干完，就会形成一个流水账，然后放到日记里存着。一切都是纯文本的，好备份，平台无关、应用无关，想看的时候随便一个编辑器都能查看，Ctrl F 搜索关键词，其实对于个人完全够用。 PlanTodo 同样坚持这种 简洁 的理念，不引入多余的复杂度，如果不想使用本应用，只是想通过它生成每日任务，可以在生成任务后，打开右上角更多菜单，里面有今日摘要，点击后就会得到文字版的任务描述。 我的流水账。
PlanTodo 是一个免费的待办应用，目前支持 Android 和 Windows ，在一个月以内会支持 iOS 、macOS 和 Linux ，实现全平台可用。 PlanTodo 的中文名是“放个计划”，从名称可见，其特色功能是“计划”。本应用将任务和计划明确区分开，任务是单次的，而计划拥有周期，条件满足时计划会被触发，然后生成相应的任务。 官网： https://plantodo.app/ 。 使用计划 定制自己的计划后，每天自动生成当天待办，进而规划一天的事情。 若想立马体验 PlanTodo 的功能，最好下载 用例 ，然后在客户端的设置页里导入，这样会加载一些精心准备的计划和进度，方便通过实际操作了解功能。 对于本应用，既可以重用计划，也可以轻用，甚至不用： 重用 就如动图所示，将一天中主要的事情都编写计划进行管理，这样每一天都可以有一个参考，促进形成习惯和保持健康生活的节奏。 轻用 就是只放周期比较特别的事情，防止忘记。比如每两个月换一次牙刷、每三周 Google Voice 保号、每三个月的周六对 NAS 进行冷备份、黑五前一周关注一些促销信息等。 不用 计划，只是将之作为一个朴素的任务安排应用。任务本身同样是本应用的重点功能，添加、编辑、删除、恢复、克隆等基本操作，开始时间、提醒、耗时、颜色标记等基本属性都有，其实计划只是节省了编写任务内容的工作。 任务安排不需要多复杂 花了半年时间开发的应用，称得上呕心沥血之作。从 4 年前读到 I tried every todo app and ended up with a .txt file — al3rez 这篇文章开始使用 纯文本 管理任务后，我就想着生成任务这一过程完全可以用程序实现，不用每天自己推理要做什么，于是就有了推理程序，有了 web ，最后有了 PlanTodo 。 个人的任务管理不需要那么花哨，能记下任务内容即可，加上耗时更好，如下是我之前记录任务的方式： 早上 07:07 起床，煮一壶水，吃早餐 30min ，安排今日工作 5min ，正式工作 2h30m ，中午吃饭 25min ，午觉 20min ，眺望(下午)，正式工作 1h30m ，正式工作 2h ，眺望，正式工作 1h30m ，做饭吃饭 1h ，吃维生素片，晚饭后出门溜达 10min ，慢跑 6min ，practice English https://www.youtube.com/watch?v=JKowwNf2CM0 20min ,晚上刷牙，看书 30min ，停止工作，上床休息，在 22:39 开始熄灯睡觉 每完成一件事就移走，如果不想干就删除，或者有临时新加的事情就打几个字，等一天的事情干完，就会形成一个流水账，然后放到日记里存着。一切都是纯文本的，好备份，平台无关、应用无关，想看的时候随便一个编辑器都能查看，Ctrl F 搜索关键词，其实对于个人完全够用。 PlanTodo 同样坚持这种 简洁 的理念，不引入多余的复杂度，如果不想使用本应用，只是想通过它生成每日任务，可以在生成任务后，打开右上角更多菜单，里面有今日摘要，点击后就会得到文字版的任务描述。 我的流水账。