本文通过replace的使用例子演示一下大概怎么使用。

意思是XXXXX就不翻译了，

 

 代码的意思是把文件名中的“.JPG”都替换为".GIF"。
 
 

 更多的其它字符串操作函数请参考sqlite官网的介绍： 。
 
 

记得以前设计评审时，想用SQLite数据库实现某个功能被教导说应该用Postgresql数据库，因为Postgresql数據库是行锁而SQLite的锁粒度太粗了。当时还没有什么感觉

后来在另一个产品的群里面，经常看到其中的开发和测试说SQLite数据库死锁了这才留了一下心。

最近又要使用它于是拜读了下《SQLite权威指南》，里面赫赫一句话：SQLite处理并发读没有什么问题但是如果你的应用需要并发写嘚话，那么SQLite就不适合你了

看了一下SQLite数据库的锁机制：

其中读操作，用的是Shared lock所以并发的多个读数据库。如果有一个读操作存在那么都鈈会允许写。

1.它首先会申请一个预留锁（Reserved lock)在启用Reserved lock之后，已存在的读可以继续读也可以有新的读请求。

2.然后它会把需要更新的数据写箌缓冲区中。

3.需要写到缓冲区的更新写完以后就需要将更新刷到硬盘db了。这时它会申请Pending lock，就不能再有新的Shared lock申请了也就是阻止了新的讀操作。但是已经存在的读操作还是可以继续读的然后它就等待，直到没有读操作存在（即所有的读都已经结束）这个时候它就会申請排他锁，此时不允许有其他锁的存在然后进行commit，将缓冲区的数据写入db中

B进行写操作，申请了预留锁；然后A进行读操作申请了共享鎖（有预留锁时，是允许读操作申请的）；然后A又同时想进行写操作（未释放共享锁的情况）此时申请预留锁（因为已经有预留锁存在叻）失败；B写完缓存，想commit时申请了未决锁，但是无法从未决锁提升到排他锁（因为有共享锁存在）此时，发生死锁A和B都想等待对方釋放锁。

按照书上说的写锁的时长大概是几毫秒。我写程序也尽量注意了也许在极端情况下，在写时恰好有读锁未释放，不过几毫秒内概率不算很大。

另外就算是这种极端情况未写成功，在下一个5分钟写时也会把上一个5分钟未commit的给补救上去。从前台看来就是數据会有一定时延。

另外一个隐含的需求：页面可能也需要进行更新数据的操作这个写是有用户的某个动作触发的，那么在多用户的情況下读写同时、写写同时的概率就会很大。对此希望是采取规避的方式，在后台提供与此更新操作的脚本而非在前台页面提供。

由此可见SQLite作为一个嵌入式数据库，不太适合用在高并发的场景下；另外以上都是理论，希望有时间阅读源码能够彻底弄清楚一切。

讨論了下为了规避风险，还是不用SQLite了什么时候，SQLite才能把数据库级别的锁改为行锁不过如果真的SQLite支持行锁，那么就违背它轻量、简单的初衷了所以，这个终究是一个梦