健身追踪应用每天都会产生大量训练日志，包括跑步距离、力量训练的组次与重量、心率区间变化、卡路里消耗等。这些数据如果只放在内存中，应用切到后台、系统回收进程或发生崩溃时就会丢失；如果每一条都实时上传到服务器，弱网、离线以及接口限流又会让写入链路变得脆弱。SQLite的嵌入式架构很适合承担本地日志存储的角色，它把日志组织在单个数据库文件中，既支持结构化查询，又能通过事务保证一组写入的原子性，不需要额外部署数据库服务。

为什么健身日志适合用SQLite而不是普通文件

把日志写入文本文件或JSON文件，确实实现简单，但随着数据量增长，查询和统计会越来越困难。比如想统计最近30天的跑步总时长，文件方案往往需要逐行解析，再在应用层做过滤聚合。SQLite则可以直接用SQL完成这类任务，而且查询计划能够利用索引，性能比全文扫描文件稳定得多。

健身日志还有明显的结构化特征，每条记录通常包含用户ID、运动类型、开始时间、持续时长、距离、平均心率等字段。把这些字段固化成表结构，可以在写入时做类型约束，避免出现把字符串写进数值列这类脏数据。SQLite的数据库文件可以随应用一起迁移，备份也只是一次文件复制，对移动端和桌面端都非常友好。

另一个容易被忽略的点是事务能力。训练日志有时不是单条写入，一次间歇跑可能同时产生阶段记录、心率采样和汇总数据。如果写到一半发生异常，文件方案可能出现半截数据，而SQLite可以包在事务里，要么全部写入，要么全部回滚，保证日志的一致性。

日志表结构与批量写入策略

训练日志表不建议设计成一张宽表，比如把步频、坡度、最大摄氧量、跑步功率等几十个字段全部塞进去。对于大部分健身场景，先把共用的核心字段抽出来，特殊类型的数据再用扩展表或JSON文本字段保存，会让维护更简单。核心字段至少应包含用户ID、日志类型、开始时间、持续时长和创建时间，数值类指标比如距离、平均心率、消耗卡路里可以根据需要保留。

下面是一张简化后的训练日志表，使用整数时间戳代替日期字符串，方便后续做范围查询和排序。

CREATE TABLE workout_logs (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    user_id INTEGER NOT NULL,
    workout_type TEXT NOT NULL,
    duration_sec INTEGER NOT NULL,
    distance_m REAL,
    heart_rate_avg INTEGER,
    started_at INTEGER NOT NULL,
    created_at INTEGER NOT NULL DEFAULT (strftime('%s','now'))
);
CREATE INDEX idx_workout_logs_user_started
ON workout_logs(user_id, started_at DESC);

单条插入虽然直观，但如果在一次训练结束时要写入几十条心率采样或阶段数据，频繁提交事务会带来明显的磁盘压力。SQLite中可以使用executemany配合参数化SQL进行批量写入，底层会在同一个事务里执行多条插入，减少每条的提交开销。下面是一段Python示例，模拟写入两条训练日志。

import sqlite3
conn = sqlite3.connect('fitness.db')
cur = conn.cursor()
logs = [
    (1, 'running', 1800, 5.2, 145, 1734567890),
    (1, 'cycling', 3600, 18.4, 132, 1734570000)
]
cur.executemany(
    'INSERT INTO workout_logs(user_id, workout_type, duration_sec, distance_m, heart_rate_avg, started_at) VALUES (?, ?, ?, ?, ?, ?)',
    logs
)
conn.commit()
conn.close()

参数化SQL不仅能防止SQL注入，还能让SQLite复用已编译的语句。对于日志写入这类高频操作，复用语句可以减少解析开销。如果写入量更大，可以进一步把多条插入放到显式事务中，例如先执行BEGIN，全部写入后再COMMIT，这样磁盘同步次数会更少。

WAL模式与并发读写优化

健身应用在前台记录训练日志的同时，界面可能还要读取历史数据绘制趋势图。如果SQLite使用默认的DELETE日志模式，写入时容易和读取产生锁竞争，表现为界面卡顿或写入延迟。切换到WAL模式后，读操作可以从快照中读取数据，不会阻塞写操作，写操作写入WAL文件后合并到主库，整体并发体验会好很多。

WAL模式通过PRAGMA命令开启，同时可以调整同步级别和自动检查点频率。synchronous设置成NORMAL，在WAL模式下既保留必要的持久性，又减少了每次提交的同步压力。

PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;
PRAGMA wal_autocheckpoint=1000;

WAL文件会随着写入不断增长，达到自动检查点条件后SQLite会将其中的内容合并回数据库主文件。如果设备存储空间紧张，可以主动调用wal_checkpoint清理WAL文件。不过在正常写入频率下，默认策略足够使用，不必频繁手动检查点，否则反而会引入额外磁盘写入。

需要注意的是，WAL模式不适合网络文件系统或多进程同时写入的场景。健身应用通常只有一个进程访问本地数据库，因此可以放心开启。只读查询在WAL模式下也不会像传统模式那样频繁等待写锁释放。

日志查询与数据清理

日志的价值不仅在于存储，还在于后续分析。比如统计某用户最近一周不同运动类型的总时长，可以直接用聚合查询完成，不需要把数据全部拉到内存中再计算。下面这条SQL按运动类型汇总时长，利用user_id和started_at索引可以快速缩小扫描范围。

SELECT workout_type,
       SUM(duration_sec) AS total_sec
FROM workout_logs
WHERE user_id = ?
  AND started_at >= ?
  AND started_at < ?
GROUP BY workout_type;

日志数据长期积累后，单表会越来越大，影响写入和查询性能。健身场景的日志通常有较强的时效性，历史数据并不需要永久保留在设备本地。可以定期删除超过180天或365天的日志，或者按用户维度归档到文件后删除。删除操作应分批进行，避免一次性删除几十万行造成长时间锁库。

除了清理，还可以为高频查询设计覆盖索引。例如只想看跑步总公里数，可以建立包含workout_type和distance_m的索引，减少回表读取。索引不是越多越好，每个索引都会增加存储空间和写入成本，应根据真实查询需求来创建。对于已经存在大量数据的表，可以先通过EXPLAIN QUERY PLAN分析查询是否真正用到了索引，再决定是否保留。

SQLite在健身追踪应用中的日志记录，本质上是在可靠性、写入性能和查询便利性之间找到平衡。只要表结构合理、批量写入使用事务、开启WAL模式并做好定期清理，单文件数据库完全可以支撑大多数个人健身应用长期稳定运行。