在使用 SQLite 进行读写操作时，出现**锁表**（table lock）通常是由于数据库的并发访问导致的。SQLite 本质上是一个文件数据库，它的并发处理能力相对有限，默认情况下，SQLite 使用锁机制来确保数据的一致性和防止竞争条件的发生。当一个事务在进行写操作时，会为整个数据库加上锁，阻止其他事务进行写入或读取，直到写操作完成。
### 出现锁表的原因：
1. **多个事务并发写入**：SQLite 在写操作时会加一个排他锁（exclusive lock），这意味着在写操作完成之前，其他读写操作都无法进行。
2. **长时间的事务未提交**：如果一个事务在执行期间没有及时提交或回滚（例如，事务执行时间过长），其他事务会被阻塞。
3. **多个连接争用资源**：如果你的程序在短时间内频繁发起多个数据库连接进行读写操作，可能会导致锁冲突。
4. **读写混合操作**：SQLite 默认使用读锁和写锁机制，多个读操作可以同时进行，但一旦发生写操作，其他的读操作就可能被阻塞。
### 避免锁表的解决方案：
1. **尽量缩短事务的执行时间**：
- 将事务的处理时间最小化，快速提交或回滚。长时间的事务会导致其他操作被锁住。
2. **优化并发访问**：
- 使用合适的锁模式，确保在同一时间只有一个写操作。可以通过合理的读写调度来减少锁冲突。
3. **使用 WAL（Write-Ahead Logging）模式**：
- SQLite 的 WAL 模式允许读写并发进行，在这种模式下，读操作不会被写操作阻塞。你可以通过以下 SQL 语句开启 WAL 模式：
```sql
PRAGMA journal_mode=WAL;
```
- WAL 模式允许读操作和写操作更好地共存，因为写操作是在独立的 WAL 文件中完成的。
4. **处理好数据库连接**：
- 尽量减少数据库连接数，重用已有连接。频繁创建和销毁连接可能导致锁冲突。
- 可以使用连接池来优化数据库连接管理。
5. **合理使用事务**：
- 将读操作和写操作分开处理，避免在同一事务中进行大量的读写混合操作。
6. **检测锁并重试**：
- 如果一个事务因锁表失败，可以设计代码在失败时稍微延迟并重试。例如，使用 `sqlite3_busy_timeout()` 函数设置忙等待时间来处理锁争用问题：
```cpp
sqlite3_busy_timeout(db, 1000); // 设置忙等待时间为 1000 毫秒
```
### 代码示例：
假设你有一个写操作，可以通过如下方式来优化：
```cpp
#include <iostream>
#include <sqlite3.h>
int execute_query(sqlite3* db, const char* sql) {
char* errMsg = 0;
int rc = sqlite3_exec(db, sql, 0, 0, &errMsg);
if (rc != SQLITE_OK) {
std::cerr << "SQL error: " << errMsg << std::endl;
sqlite3_free(errMsg);
}
return rc;
}
int main() {
sqlite3* db;
int rc = sqlite3_open("example.db", &db);
// 设置 WAL 模式
execute_query(db, "PRAGMA journal_mode=WAL;");
// 设置忙等待时间
sqlite3_busy_timeout(db, 1000); // 等待 1000 毫秒
if (rc) {
std::cerr << "Can't open database: " << sqlite3_errmsg(db) << std::endl;
return rc;
} else {
std::cout << "Opened database successfully" << std::endl;
}
// 开始一个事务
execute_query(db, "BEGIN TRANSACTION;");
// 执行插入操作
execute_query(db, "INSERT INTO test (name, age) VALUES ('John', 30);");
// 提交事务
execute_query(db, "COMMIT;");
sqlite3_close(db);
return 0;
}
```
这个代码中，我们开启了 WAL 模式并设置了忙等待时间来减少锁表的几率。
