Sakurasan
117e03673b
perf(sqlite): 写事务改 immediate + synchronous=NORMAL，单 worker 批 64
上一轮发现「多 worker 在 SQLite 上更慢」，这轮把它当成一个可调优问题重新测：
基准（2000 条记账、暖机后跑稳态，同一台机器反复 3 次取分布）：
- 默认 deferred 事务 + batch 32：11k–20k rows/s，抖动极大（并发写升级锁失败触发
SQLITE_BUSY 重试，这正是之前 p99 飙到 19–34ms 的原因）
- _txlock=immediate + batch 32：28.2–28.5k rows/s，抖动收敛
- _txlock=immediate + batch 64 + synchronous=NORMAL：29.7–30.1k rows/s，波动 <1%
- 同样配置下 2 个 worker：7.7k–16.7k，仍更差（SQLite 只有一个写者）
因此：
- store.withSQLitePragmas 增加 _txlock=immediate 与 _pragma=synchronous(NORMAL)；
immediate 让写事务在 BEGIN 就取写锁，消除升级冲突；NORMAL 是 WAL 下的标准配置，
提交不再逐次 fsync（代价：断电可能丢最后一个事务，已在注释里写明）。
- 记账批大小按驱动区分：SQLite 单 worker 用 64，PG 保持 32。
- 保持 SQLite 单 worker（数据不支持多 worker）。
端到端复测（16 并发、mock 上游）：p50 649µs→548µs、p99 2.32ms→1.60ms、
RPS 21.2k→24.9k；对比本轮开始前的 18.7k/2.2ms 亦有改善。
验证：go vet、go test ./...、go test -race（usage/proxy/store）全绿。
2026-10-30 16:08:55 +08:00
..
2026-10-30 14:14:21 +08:00
2026-10-30 01:42:54 +08:00
2026-10-30 14:25:10 +08:00
2026-10-30 14:14:21 +08:00
2026-10-30 14:14:21 +08:00
2026-10-30 01:42:54 +08:00
2026-10-30 14:14:21 +08:00
2026-10-30 14:25:10 +08:00
2026-10-30 16:08:55 +08:00
2026-10-30 16:08:55 +08:00