SQLite 并发访问 [英] SQLite Concurrent Access

问题描述

SQLite3 是否安全地处理多个进程的并发访问从同一个数据库读/写?是否有任何平台例外?

Does SQLite3 safely handle concurrent access by multiple processes reading/writing from the same DB? Are there any platform exceptions to that?

推荐答案

如果大多数并发访问是读取(例如 SELECT)，SQLite 可以很好地处理它们.但是如果你开始并发写入，锁争用可能会成为一个问题.很大程度上取决于您的文件系统有多快，因为 SQLite 引擎本身非常快，并且有许多巧妙的优化来最大程度地减少争用.尤其是 SQLite 3.

If most of those concurrent accesses are reads (e.g. SELECT), SQLite can handle them very well. But if you start writing concurrently, lock contention could become an issue. A lot would then depend on how fast your filesystem is, since the SQLite engine itself is extremely fast and has many clever optimizations to minimize contention. Especially SQLite 3.

对于大多数桌面/笔记本电脑/平板电脑/手机应用程序，SQLite 足够快，因为并发性不够.(Firefox 广泛使用 SQLite 来制作书签、历史记录等)

For most desktop/laptop/tablet/phone applications, SQLite is fast enough as there's not enough concurrency. (Firefox uses SQLite extensively for bookmarks, history, etc.)

对于服务器应用，前段时间有人说，在典型场景(例如博客、论坛)下，一天不到100K的页面浏览量都可以通过SQLite数据库完美处理，我还没有看到任何相反的证据.事实上，使用现代磁盘和处理器，95% 的网站和网络服务都可以与 SQLite 配合使用.

For server applications, somebody some time ago said that anything less than 100K page views a day could be handled perfectly by a SQLite database in typical scenarios (e.g. blogs, forums), and I have yet to see any evidence to the contrary. In fact, with modern disks and processors, 95% of web sites and web services would work just fine with SQLite.

如果您想要真正快速的读/写访问，请使用内存 SQLite 数据库.RAM 比磁盘快几个数量级.

If you want really fast read/write access, use an in-memory SQLite database. RAM is several orders of magnitude faster than disk.

这篇关于SQLite 并发访问的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！