如果：
- 您为所有线程仅使用一个数据库连接；
- 您使用全局临界区保护您的数据库连接访问。
那么您的应用程序速度是多少？然后您可以尝试我们的 Sqlite3静态绑定，它是在未编译线程互斥锁的情况下编译的：
#define SQLITE_THREADSAFE 2
// assuming multi-thread safety is made by caller - in our framework, there is
// only one thread using the database connection at the same time, but there could
// be multiple database connection at the same time (previous was 0 could be unsafe)
#define SQLITE_OMIT_SHARED_CACHE 1
// no need of shared cache in a threadsafe calling model
我们在mORMot ORM框架中使用这样的模型，并且与四个级别的缓存相关：
- 语句缓存用于重复使用SQL语句，并动态绑定参数；
- 全局JSON结果缓存位于数据库层，会在任何INSERT / UPDATE时全局刷新；
- 调整过的记录缓存位于服务器端指定表格或记录的CRUD / RESTful级别；
- 调整过的记录缓存位于客户端指定表格或记录的CRUD / RESTful级别。
结果性能并不差 - 它可以很好地扩展到多线程访问中，即使存在全局关键部分。当然，
SQlite3的设计并不像Oracle那样良好扩展！但我已经在实际应用中使用了SQlite，有很多客户端。您可以考虑使用具有更复杂（和调整）的客户端 - 服务器体系结构的
FireBird。
关于加快写作速度，您可以将您的文章分组为一个事务，这样会更快。这就是我使用
加速写作 的方法，您可以通过多个客户端扩展这个概念：在服务器端，您将您的写入重新分组到一个共享事务中，在超时时间（例如一秒钟）后提交该事务。
对于这种添加操作，SQLite3非常快（甚至使用绑定参数的预准备INSERT语句更快），但对于单个添加操作则很慢，因为它必须使用低级API锁定整个文件，这非常慢。为了使其符合ACID标准，确保提交总是被处理。实际上，其他数据库引擎通过类似的在后台隐藏的过程实现良好的并发速度。SQLite3默认的写入方法被期望是这样的，以确保多个进程可以访问同一个文件 - 但在您的客户端-服务器应用程序中，您只需依赖于您将是唯一访问SQLite3数据库文件的人，因此它将是安全的。
