SQLite 的鎖定機制

SQLite 是一個基於檔案的資料庫，它的併發控制相對單純。當一個進程或執行緒想要寫入資料時，SQLite 會對整個資料庫檔案加上排他鎖（Exclusive Lock）。在預設的資料庫模式下，當某個連線正在寫入，其他連線的讀取或寫入請求都會被阻擋。如果寫入操作耗時過長，其他嘗試寫入的連線會因為等不到鎖而拋出 sqlite3.OperationalError: database is locked 的錯誤。

Python 與 FastAPI 的影響

FastAPI 通常運行在非同步環境下，但標準的 sqlite3 套件是同步的。如果你在 FastAPI 中使用多執行緒（例如透過 thread pool 執行同步函式），多個執行緒同時存取同一個資料庫連線會引發程式崩潰，因為 sqlite3 預設不允許跨執行緒共享連線。即使每個執行緒都有獨立連線，上述的檔案鎖問題依然存在。此外，Python 有全域解釋器鎖（GIL），雖然這在處理 I/O 密集任務時影響較小，但它確保了 Python bytecode 一次只會由一個核心執行，這並不能解決資料庫層級的競爭問題。

如何減少存取錯誤

要讓 SQLite 在多人同時寫入時更穩定，最有效的做法是開啟預寫式日誌（WAL）模式。在 WAL 模式下，讀取和寫入可以同時進行，不會互相阻塞。你可以透過執行 PRAGMA journal_mode=WAL; 來切換。另外，設定適當的 timeout 參數也很重要。在建立連線時設定 sqlite3.connect(db_file, timeout=20)，這會讓連線在遇到鎖定時先等待一段時間，而不是立即報錯。

替代方案與考量

如果你的應用場景真的有非常頻繁的併發寫入需求，SQLite 可能不是最佳選擇。雖然 WAL 模式能改善情況，但 SQLite 終究是為了單機或中輕量級應用設計的。當寫入衝突頻繁到 timeout 都無法解決時，改用像 PostgreSQL 這種客戶端伺服器架構的資料庫會是比較根本的解決辦法，因為它們能處理更細粒度的行級鎖定（Row-level locking），在多核心環境下發揮更好的效能。

要在 Python 的 sqlite3 模組中啟用 WAL 模式，你需要在建立資料庫連線後執行一段 PRAGMA 指令。這個設定會儲存在資料庫檔案中，但通常建議在每次程式啟動連線時都確認一次。

啟用 WAL 模式的步驟

在 Python 中，你可以透過執行 execute 方法來切換模式。這會將日誌模式從預設的 DELETE 改為 WAL。

import sqlite3

# 建立連線，建議加上 timeout 避免 busy 錯誤
conn = sqlite3.connect('example.db', timeout=10)

# 啟用 WAL 模式
conn.execute('PRAGMA journal_mode=WAL;')

# 驗證是否成功切換
cursor = conn.execute('PRAGMA journal_mode;')
print(f"目前模式為: {cursor.fetchone()[0]}")

conn.close()

為什麼要在連線時設定

雖然 WAL 模式一旦設定後會持久化在資料庫標頭中，但在程式碼中明確執行這行指令有助於確保環境一致。當你啟用 WAL 後，你會發現資料庫目錄下多了兩個暫存檔（結尾為 -wal 與 -shm），這是正常現象。

在 FastAPI 中的建議配置

如果你在 FastAPI 中使用，建議在建立連線的工具函式或是 SQLAlchemy 的 engine 配置中加入這個設定。如果你使用 SQLAlchemy，可以使用 event listener 來自動執行。

from sqlalchemy import create_engine, event

engine = create_engine("sqlite:///./test.db")

@event.listens_for(engine, "connect")
def set_sqlite_pragma(dbapi_connection, connection_record):
    cursor = dbapi_connection.cursor()
    cursor.execute("PRAGMA journal_mode=WAL")
    cursor.execute("PRAGMA synchronous=NORMAL")
    cursor.close()

這裡額外加入了 PRAGMA synchronous=NORMAL;，在 WAL 模式下配合這個設定可以大幅提升寫入速度，同時兼顧資料安全性。

修改 php.ini 設定檔

請先打開 XAMPP Control Panel 控制面板。點擊 Apache 該列的 Config 按鈕，選擇 php.ini 項目。

檔案打開後，使用搜尋功能尋找 extension=sqlite3。你會看到前面有一個分號，這代表該行被註解掉了。請刪除該行最前面的分號，修改後應該長這樣：

extension=sqlite3

接著搜尋 extension=pdo_sqlite，同樣確認前面的分號已經移除。這能確保 PDO 模式的 SQLite 也能正常運作。

重啟 Apache 服務

儲存 php.ini 檔案後回到 XAMPP 控制面板。點擊 Apache 的 Stop 按鈕停止服務。等待幾秒鐘後，再次點擊 Start 重新啟動。

重啟是為了讓 PHP 載入剛才修改的設定。現在重新整理網頁，錯誤應該就會消失。

確認環境變數

如果重啟後還是報錯，可能是缺少相關的 DLL 檔案。請確認 XAMPP 安裝目錄下的 php 資料夾中，是否存在 php_sqlite3.dll。

通常 XAMPP 都會內建這個檔案。若檔案存在卻無法讀取，請檢查 php.ini 裡的 extension_dir 是否指向正確的 ext 路徑。

你可以建立一個 info.php 檔案，內容寫入 phpinfo() 函式。在瀏覽器執行該檔案並搜尋 SQLite，就能確認模組是否成功掛載。

sqlite 官方下戴點:
https://sqlite.org/download.html

sqlite3 WebAssembly & JavaScript Documentation
https://sqlite.org/wasm/doc/trunk/index.md

使用的範例:
https://sqlite.org/wasm/doc/trunk/demo-123.md

如果是只有要在 chrome browser 上跑的話, 是可以使用 WebSQL, This is the deprecated SQLite interface that is built into Chrome. It does not use WASM. It is coded directly in C/C++. WebSQL only runs in the main thread. WebSQL 在少量資料與巨量資料下的反應時間都比 sqlite3 來的優異, 參考看看效能比較表:
https://sqlite-wasm-opfs.glitch.me/speedtest.html

目前所有瀏覽器都可以用的是 Indexed Database:
https://www.w3.org/TR/IndexedDB/

IndexedDB 與 sql.js 那邊跑的較快?

使用這組 keyword 問 google: indexeddb sqlite wasm performance
https://sqlite.org/forum/info/4a97813fcbd4f63e?t=h

We did not benchmark against IndexedDb because, frankly, IndexedDb doesn’t really concern us. It’s a whole different beast with a whole different API, and any sort of comparisons would be apples vs. oranges. We experimented only very briefly (a single afternoon) with using IDB as backing store for an sqlite db, but we didn’t like where that was headed. That approach simply doesn’t sit well with any of us.

The speed of non-persistent I/O is essentially limited to that of the underlying JS and WASM engines. All we can really do there, in terms of influencing the speed, is compile at different optimization levels. (Compiling with -O2 consistently gives faster results than any other level.)

We don’t have any truly user-friendly benchmarking tools, as we just use them during testing and development, but they’re accessible at:

https://wasm-testing.sqlite.org/

In particular, the “speedtest1” tools are our basis for benchmarking because they’re WASM builds of the C library’s primary benchmarking tool. Using that, we can do direct comparisons against “native” (out-of-browser) speeds.

Persistence. I know that Chrome’s new APIs make file system persistence possible, but I think it’s really important that we have an IndexedDb (or equiv) fallback.

cough localStorage cough sessionStorage cough

An IDB-based backend is not currently in the cards for this project. There are other projects which store sqlite in IDB:

• https://github.com/jlongster/absurd-sql
• https://github.com/rhashimoto/wa-sqlite
  Figuring out whether/how it’s possible to import wa-sqlite’s VFSes into client-level code which uses our API is on my TODO list. That would be a huge win, as Roy has done some amazing work on providing a framework for building and testing new VFSes.

This is not to be misunderstood as an official project-level stance on the topic, but i’m personally in no way keen on supporting IDB. That said, my strongly negative opinion on IDB is admittedly based mostly on the anecdotes of others, rather than personal experience, and counter-anecdotes would be dutifully considered¹. Even so, the list of JS/WASM TODOs and want-to-dos is long enough that, even if someone were to convince us that an IDB-based implementation was worth the effort of development and supporting it forever, it’s unlikely that it would actually get done before the middle of 2023. By that time, the non-Chromium browsers will certainly (we can hope) have caught up with OPFS, making IDB a non-topic for us.

sqlite3 官方版本的使用範例.

Step 1: Create the HTML

loads main sqlite3.js

<!doctype html>
<html lang="en-us">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>Hello, sqlite3</title>
  </head>
  <body>
    <script src="jswasm/sqlite3.js"></script>
    <script src="demo-123.js"></script>
  </body>
</html>

Step 2: Create a JS App

window.sqlite3InitModule().then(function(sqlite3){
  // The module is now loaded and the sqlite3 namespace
  // object was passed to this function.
  console.log("sqlite3:", sqlite3);
});

附上的測試用的範例:

window.sqlite3InitModule().then(function(sqlite3){
  	// The module is now loaded and the sqlite3 namespace
  	// object was passed to this function.
  	console.log("sqlite3:", sqlite3);
    sqlite3.config.warn("Installing sqlite3 bits as global S for local dev/test purposes.");
    window.S = sqlite3;
    capi = sqlite3.capi;
    wasm = sqlite3.wasm;
    console.log("sqlite3 version:",capi.sqlite3_libversion(),
        capi.sqlite3_sourceid());
    if(wasm.bigIntEnabled){
      console.log("BigInt/int64 support is enabled.");
    }else{
      console.log('warning',"BigInt/int64 support is disabled.");
    }
  
  const oo = sqlite3.oo1; /*high-level OO API*/
  let db;
  if (sqlite3.opfs) {
    db = new sqlite3.opfs.OpfsDb('/mydb.sqlite3');
    console.log('The OPFS is available.');
  } else {
    db = new oo.DB('/mydb.sqlite3', 'ct');
    console.log('The OPFS is not available.');
  }
  console.log('transient db =', db.filename);

  try {
    console.log('Create a table...');
    db.exec('CREATE TABLE IF NOT EXISTS t(a,b)');
    console.log('Insert some data using exec()...');
    let i;
    for (i = 20; i <= 25; ++i) {
      db.exec({
        sql: 'INSERT INTO t(a,b) VALUES (?,?)',
        bind: [i, i * 2],
      });
    }
    console.log("Query data with exec() using rowMode 'array'...");
    db.exec({
      sql: 'SELECT a FROM t ORDER BY a LIMIT 3',
      rowMode: 'array', // 'array' (default), 'object', or 'stmt'
      callback: function (row) {
        console.log('row ', ++this.counter, '=', row);
      }.bind({ counter: 0 }),
    });
  } finally {
    db.close();
  }
});

瀏覽器 console 裡的訊息:

You can use the available meta data:

  DatabaseMetaData meta = con.getMetaData();
  ResultSet res = meta.getTables(null, null, "My_Table_Name", 
     new String[] {"TABLE"});
  while (res.next()) {
     System.out.println(
        "   "+res.getString("TABLE_CAT") 
       + ", "+res.getString("TABLE_SCHEM")
       + ", "+res.getString("TABLE_NAME")
       + ", "+res.getString("TABLE_TYPE")
       + ", "+res.getString("REMARKS")); 
  }

See here for more details. Note also the caveats in the JavaDoc.

解法，先把 string 轉 python datetime:

from datetime import datetime

birthday_object = datetime.strptime(birthday, '%Y-%m-%d')

然後把 birthday_object 直接餵進去 sqlite 裡，

sqlite 的 select 用：

SELECT julianday('now') - julianday(DateCreated)

答案就出來一半了，接下來可以用 python 處理，也可以用 sqlite, 如果是用 sqlite:

Difference In Days

Select Cast ((
    JulianDay(ToDate) - JulianDay(FromDate)
) As Integer)

Difference In Hours

Select Cast ((
    JulianDay(ToDate) - JulianDay(FromDate)
) * 24 As Integer)

Difference In Minutes

Select Cast ((
    JulianDay(ToDate) - JulianDay(FromDate)
) * 24 * 60 As Integer)

Difference In Seconds

Select Cast ((
    JulianDay(ToDate) - JulianDay(FromDate)
) * 24 * 60 * 60 As Integer)

from：

https://www.sqlite.org/lang_datefunc.html