better-sqlite3 分页查询与事务处理的陷阱分析

在使用 better-sqlite3 进行数据库操作时，分页查询与事务处理的结合使用可能会产生一些意想不到的结果。本文将通过一个典型案例，深入分析这种现象背后的原因，并提供解决方案。

问题现象

开发者尝试实现一个分页查询功能，每页获取10条记录，然后对这些记录进行事务性更新。初始实现如下：

1. 创建包含100条记录的测试表
2. 使用OFFSET和LIMIT进行分页查询
3. 在事务中对查询结果进行更新

然而运行后发现，实际更新的ID序列出现了跳跃现象，如1-10后直接跳到21-30，而不是预期的11-20。

原因分析

这种现象的根本原因在于SQLite查询执行机制与事务处理的交互：

1. 条件过滤的影响：查询使用了foo IS NULL条件，而事务中对记录的更新会修改这个字段值
2. 偏移量的累积效应：每次查询后offset增加10，但前10条记录被更新后不再满足查询条件
3. 结果集动态变化：事务提交后，已更新的记录从结果集中"消失"，导致后续查询跳过更多记录

简单来说，当第一页(1-10)记录被更新后，这些记录不再满足foo IS NULL条件。第二页查询时，数据库会跳过前10条(已更新)和接下来的10条(offset 10)，实际返回的是原始的第21-30条记录。

解决方案

针对这种场景，推荐以下几种解决方案：

方案一：使用游标而非偏移量

let lastId = 0;
const limit = 10;

while (true) {
  const results = db.prepare(
    `SELECT id FROM bar WHERE foo IS NULL AND id > ? ORDER BY id LIMIT ${limit}`
  ).all(lastId);

  if (results.length === 0) break;
  
  lastId = results[results.length - 1].id;
  // 处理results...
}

这种方法基于ID排序和过滤，不受中间记录更新的影响。

方案二：先查询全部ID再分批处理

const allIds = db.prepare(
  `SELECT id FROM bar WHERE foo IS NULL ORDER BY id`
).all().map(row => row.id);

for (let i = 0; i < allIds.length; i += 10) {
  const batch = allIds.slice(i, i + 10);
  // 处理batch...
}

这种方法在内存中保存所有符合条件的ID，然后分批处理，确保不会遗漏任何记录。

方案三：使用临时表或CTE

db.transaction(() => {
  // 创建临时表保存需要处理的ID
  db.prepare(`
    CREATE TEMPORARY TABLE temp_ids AS 
    SELECT id FROM bar WHERE foo IS NULL ORDER BY id LIMIT 10
  `).run();
  
  // 处理这些ID
  const ids = db.prepare(`SELECT id FROM temp_ids`).all();
  // 更新操作...
  
  // 删除临时表
  db.prepare(`DROP TABLE temp_ids`).run();
})();

这种方法通过临时表锁定需要处理的记录，避免并发修改的影响。

最佳实践建议

1. 对于大型数据集，优先考虑基于游标的分页方式
2. 在可能发生并发修改的场景下，避免使用OFFSET分页
3. 考虑使用事务隔离级别来控制查询的可见性
4. 对于关键业务操作，可以先锁定记录再处理

理解这些底层机制，可以帮助开发者更好地设计可靠的数据处理流程，避免在实际应用中出现数据遗漏或重复处理的问题。