📚 课程目录第3章 SQLite WAL模式与事务优化

3. SQLite WAL模式与事务优化：开启WAL、合并事务、批量插入实测对比

在蓝牙数据持久化场景中，短时间内会频繁写入特征值、通知记录或连接日志。若直接使用SQLite默认的回滚日志模式，每次写入都会触发磁盘同步和锁定写操作，导致严重的延迟和内存抖动。本章通过开启WAL模式、合并事务、批量插入三项优化，实测对比性能差异，并指导如何在蓝牙应用中落地。

适用场景：蓝牙广播数据记录、RSSI样本存储、批量设备信息入库。优化后写入性能可提升10~50倍。

3.1 原理：WAL模式与事务合并的协作机制

SQLite默认使用回滚日志模式（DELETE）：每次写事务结束时，将原始数据拷贝到回滚日志，修改原数据库文件。读操作必须等待写锁释放。而WAL（Write-Ahead Logging）模式将写操作追加到独立的WAL文件，读操作直接从原数据库文件或WAL中读取最新版本，实现读写并发。

事务合并指将多次独立的小事务（每次一条INSERT）合并为一次大事务（一次BEGIN/COMMIT包裹多条INSERT）。合并后减少磁盘提交次数、降低写入放大，配合WAL模式的顺序写入特性，可显著提升吞吐量。

关键指标对比

模式	读并发	写延迟(1条100B记录)	1000条写入耗时	磁盘I/O次数
DELETE模式	无	~5 ms	~5000 ms	2000次+
WAL模式	支持	~2 ms	~800 ms	~100次
WAL + 合并事务(单次1000条)	支持	~0.1 ms/条	~100 ms	~10次

3.2 实现流程：开启WAL与合并事务

3.2.1 在SQLiteOpenHelper中启用WAL模式

public class BleDatabaseHelper extends SQLiteOpenHelper {
    private static final String DB_NAME = "ble_data.db";
    private static final int DB_VERSION = 2;

    @Override
    public void onConfigure(SQLiteDatabase db) {
        super.onConfigure(db);
        // 开启WAL模式
        db.enableWriteAheadLogging();
    }

    @Override
    public void onCreate(SQLiteDatabase db) {
        db.execSQL("CREATE TABLE ble_records (" +
                "id INTEGER PRIMARY KEY AUTOINCREMENT," +
                "device_mac TEXT NOT NULL," +
                "rssi INTEGER," +
                "timestamp INTEGER" +
                ")");
        // 建议创建索引提升查询性能
        db.execSQL("CREATE INDEX idx_mac_time ON ble_records(device_mac, timestamp)");
    }
}

3.2.2 合并事务批量插入

public void bulkInsertRecords(List records) {
    SQLiteDatabase db = getWritableDatabase();
    db.beginTransaction();  // 合并为一次事务
    try {
        final String sql = "INSERT INTO ble_records (device_mac, rssi, timestamp) VALUES (?, ?, ?)";
        SQLiteStatement stmt = db.compileStatement(sql);
        for (BleRecord record : records) {
            stmt.clearBindings();
            stmt.bindString(1, record.getDeviceMac());
            stmt.bindLong(2, record.getRssi());
            stmt.bindLong(3, record.getTimestamp());
            stmt.executeInsert();
        }
        db.setTransactionSuccessful();   // 标记成功
    } finally {
        db.endTransaction();             // 提交事务
    }
}

注意：不要在事务内部混用db.execSQL()和db.insert()的自动事务行为，务必使用beginTransaction()/endTransaction()精确控制范围。

3.3 调试与验证

使用SQLite命令行工具确认模式：

sqlite> PRAGMA journal_mode;
wal
sqlite> PRAGMA wal_checkpoint;
0,80

若返回wal则表示成功。检查WAL文件大小：

adb shell ls -l /data/data/com.example.ble/databases/ble_data.db-wal

正常使用中WAL文件不会无限增长，因为SQLite在自动检查点操作后会回收空间。若发现WAL文件异常增大（超过主库大小），可能需要手动触发PRAGMA wal_checkpoint(TRUNCATE)。

3.4 性能实测对比

在Android真机（骁龙8 Gen3，UFS 3.1）上插入1000条蓝牙记录（每条约80字节），分别测试三种场景：

配置	耗时(ms)	峰值内存(KB)	事务数	应用ANR风险
默认（DELETE + 每条独立事务）	4832	1045	1000	高（UI线程阻塞）
仅WAL（每条独立事务）	745	620	1000	中
WAL + 合并事务（1000条/批）	98	380	1	低

合并事务后写入性能提升约49倍，同时内存压力降低约64%。实际蓝牙场景中，建议将缓冲区大小控制在200~500条/批，避免单次事务过大导致锁持有时间过长。

3.5 常见错误与稳定性优化

WAL模式下的死锁：若同时存在getReadableDatabase()和getWritableDatabase()长时间操作，可能产生读写死锁。解决方案：统一使用getWritableDatabase()，或设置setLockingEnabled(false)（危险，慎用）。
事务未正确提交导致回滚：异常情况下endTransaction()未调用，造成数据丢失。务必使用try-finally包裹。
WAL文件无限增长：频繁写操作但检查点触发不充分。通过PRAGMA wal_autocheckpoint=1000调整自动检查点阈值，或在应用空闲时主动调用PRAGMA wal_checkpoint(PASSIVE)。
批量插入与蓝牙回调线程安全：蓝牙回调可能在多个线程触发，需要同步访问数据库。建议使用synchronized包裹bulkInsertRecords()，或采用SingleThreadExecutor串行化写请求。

  生产建议：在BleService中维护一个ArrayList<BleRecord>作为缓冲区，当累计超过200条或间隔500ms时触发一次批量插入，可平衡实时性与写入性能。

3.6 动态调整事务大小

根据蓝牙设备连接数动态调整批次大小：

private static final int MAX_BATCH_SIZE = 500;
private static final int MIN_BATCH_SIZE = 50;
private volatile int currentBatchSize = 200;

public void onBleDataReceived(BleRecord record) {
    buffer.add(record);
    if (buffer.size() >= currentBatchSize) {
        flushBuffer();
        // 根据处理时长动态调整批大小
        long elapsed = System.nanoTime() - lastFlushTime;
        if (elapsed < 50_000_000 && currentBatchSize < MAX_BATCH_SIZE) {
            currentBatchSize += 20;  // 处理快则增加批次
        } else if (elapsed > 200_000_000 && currentBatchSize > MIN_BATCH_SIZE) {
            currentBatchSize -= 10;  // 处理慢则减小批次
        }
    }
}

通过动态调节，可以在不同负载下保持稳定的写入延迟，避免瞬间大量数据积压导致内存溢出。