FreeSql批量插入分表数据时SQLite锁库问题分析

问题现象

在使用FreeSql进行SQLite数据库操作时，开发人员遇到了一个典型的分表批量插入问题。当尝试批量插入300条数据到按日期分表的实体时，系统抛出"database is locked"异常。然而，当减少数据量至30条或预先手动创建表结构后，操作却能成功执行。

问题根源

这一现象的根本原因在于SQLite数据库的事务机制与FreeSql自动建表功能的冲突。SQLite采用单一事务级别设计，当开启事务后会对整个数据库进行锁定。而FreeSql在批量插入时会自动开启事务，同时在遇到表不存在时又会触发自动建表功能。

具体表现为：

1. 批量插入操作启动事务，锁定数据库
2. 在事务执行过程中发现目标分表不存在
3. 尝试创建新表时因数据库已被锁定而失败
4. 系统抛出"database is locked"异常

解决方案

针对这一问题，我们推荐以下几种解决方案：

方案一：预先创建表结构

在执行批量插入前，先通过查询操作触发表的自动创建：

freeSql.Select<Test>().AsTable((a,b)=>formattedDate).ToOne();

这种方法利用了FreeSql的自动建表功能，在事务开始前确保表结构存在。

方案二：减少批量操作规模

将大批量操作拆分为多个小批次执行，每批次数据量控制在SQLite能够处理的范围内。这种方法虽然简单，但可能影响整体性能。

方案三：手动管理事务

通过显式控制事务范围，确保建表操作在事务之外完成：

// 先确保表存在
freeSql.Ado.ExecuteNonQuery($"CREATE TABLE IF NOT EXISTS {formattedDate} (...)");

// 然后开启事务进行批量插入
using (var uow = freeSql.CreateUnitOfWork()) 
{
    freeSql.Insert(dats).AsTable(formattedDate).ExecuteAffrows();
    uow.Commit();
}

最佳实践建议

1. 生产环境预建表：在生产环境中，建议预先创建所有可能用到的分表，避免运行时自动建表带来的不确定性。

2. 合理设置批量大小：根据SQLite的性能特点，合理设置每批次处理的数据量，通常建议控制在100-200条之间。

3. 监控与重试机制：实现针对锁库异常的监控和自动重试逻辑，提高系统健壮性。

4. 考虑分表策略优化：评估是否可以通过调整分表策略（如按周/月分表而非按日）来减少建表频率。

技术原理深入

SQLite采用文件级锁来实现事务隔离，这意味着：

1. 写事务会获取排他锁，阻止其他读写操作
2. 读事务会获取共享锁，允许并发读但阻止写操作
3. 锁的粒度是整个数据库文件，而非单个表

FreeSql的自动建表功能在检测到表不存在时，会尝试执行CREATE TABLE语句，这本质上是一个写操作。当这个操作发生在已有事务内部时，就会因锁冲突而失败。

理解这一机制后，开发者就能更好地规划数据库操作流程，避免类似的并发问题。