看到這個熱榜聚合網站直接用 SQLite 做後端，很多人第一反應大概是：這玩意兒能撐住高併發嗎？說實話，如果把 SQLite 拿去搞電商秒殺或者社群論壇的高頻寫入，那絕對是災難。但在這個特定的熱榜聚合場景下，情況就有點不一樣了。這網站本質上是一個「讀多寫少」的應用，前端無數次刷新頁面都是讀取數據，而寫入只有寶塔計畫任務每五分鐘跑一次去拉取最新熱榜。
讀寫場景決定了資料庫的命運
SQLite 的底層是檔案級別的鎖定機制。在預設情況下，如果有人在寫入，整個資料庫檔案就會被鎖住，其他讀取請求只能排隊等待。這聽起來很糟，對吧？但別急著下定論。其實從 SQLite 3.7.0 版本開始引入的 WAL (Write-Ahead Logging) 模式，讓它支援了多個讀取與一個寫入並行操作。也就是說，只要你的網站不是每秒鐘都有幾百個 INSERT 或 UPDATE，光是 SELECT 查詢，SQLite 處理起來其實非常快，甚至因為少了網路層的開銷，在小資料量下比 MySQL 還要猛。
實際案例中的瓶頸在哪裡？
回到這個熱榜聚合網站的架構來看，它的高併發風險點根本不在資料庫本身，而是在 PHP 的處理能力與伺服器配置。每五分鐘一次的 cron.php 抓取更新，寫入量頂多就是幾百條記錄的更新，這對 SQLite 來說連塞牙縫都不夠。真正的壓力在於：如果某天某個平台熱搜爆了，幾萬人同時湧入你的網站看熱榜，這時候 Nginx/Apache 的進程數、PHP-FPM 的 worker 配置才是真正的瓶頸。資料庫這邊只要開啟了 WAL 模式，讀取是完全不阻塞的，響應速度能達到毫秒級。
什麼時候該換掉 SQLite？
那到底什麼時候才需要拋棄 SQLite 換成 MySQL 或 PostgreSQL 呢？其實標準很簡單，當你的「寫入」開始頻繁到出現 database is locked 報錯時。比如你哪天心血來潮，給這個熱榜網站加了用戶評論功能、用戶點讚功能，這些都是即時的高頻寫入操作。一旦併發寫入請求堆積，SQLite 的鎖機制就會成為致命傷，前端頁面會直接卡死。另外，如果你的熱榜歷史數據量累積到幾百萬條，需要做複雜的聯表查詢和聚合分析，或者你需要多台伺服器做負載平衡，SQLite 單檔案的特性就完全不適用了。總結來說，對於這種單機部署、讀多寫少的工具站，SQLite 不僅適合，甚至是性價比最高的選擇，但業務邏輯一旦變複雜，及早遷移才是正解。
評論（7）
原來開了 WAL 模式就能並行讀取，長知識了
讀多寫少的場景用 SQLite 真的很省事，不用額外裝資料庫
如果之後要加留言功能是不是就得直接換 MySQL 了？
瓶頸在 PHP-FPM 那邊挺合理的，前端狂刷頁面確實吃 process
好奇如果資料量到幾百萬條，查詢效能還能維持毫秒級嗎
單機部署用這個方案性價比真的高
database is locked 這個報錯之前遇過，原來是頻繁寫入造成的