多应用访问下SQLite数据库锁机制疑问及场景咨询

嘿，首先得说你的判断没毛病——SQLite的核心锁机制确实是多读单写的，但实际运行起来还有几个值得注意的点，刚好匹配你现在的Java写+C#读的场景：

• 多读取完全安全无冲突：只要没有写入操作在执行，任意数量的读连接（比如你的C#应用）都可以同时访问数据库，它们会共享一个读锁，互相不会阻塞对方。
• 写入时的排他性有前提：当Java应用开始一个写入事务时，SQLite会获取排他锁，这时候所有其他连接（包括读连接）都会暂时等待，直到这个写入事务完成。不过你说每秒1个事务、每个事务多条插入——只要你的事务逻辑不复杂，执行速度会非常快，这种等待几乎是用户感知不到的。
• 批量插入的事务方式很赞：你Java应用用“每秒1个事务+多条插入”的模式其实很高效，因为事务提交的开销被分摊了，比单条插入提交要省很多资源，也能减少锁持有时间。
• WAL模式能让读写彻底并行：如果你的场景里偶尔出现读写互相等待的情况（比如C#应用跑大查询时刚好撞上写入），可以试试开启SQLite的WAL（Write-Ahead Logging）模式。开启后，读操作和写操作可以同时进行：读请求会访问数据库的旧版本快照，不用等写入完成；而写入操作也不会被读请求阻塞。开启方式很简单，只需要在任意连接里执行一次这个命令，设置会被持久化到数据库：

  PRAGMA journal_mode=WAL;
  

• 不必过度担心冲突：以你现在的写入频率（每秒1次），哪怕不用WAL模式，读写之间的冲突概率也极低，几乎不会影响两个应用的正常运行。

内容的提问来源于stack exchange，提问作者Tacitus86