Performance

「奇怪，我明明刪了 52 萬筆資料，為什麼資料表還是 207MB？」 這是我今天在清理資料庫時遇到的真實情況。如果你也曾經困惑過這個問題，這篇文章會告訴你背後的原因。 事情是這樣的 專案的 user_notifications 資料表累積了幾十萬筆推播通知記錄，佔用了 207MB 空間。為了控制資料庫大小，我寫了一個 cron job 來清理超過 7 天的舊資料： // 刪除 7 天前的通知 const sevenDaysAgo = new Date(Date.now() - 7 * 24 * 60 * 60 * 1000); await strapi.db.query('api::user-notification.user-notification').deleteMany({ where: { createdAt: { $lt: sevenDaysAgo.toISOString() } }, }); 執行結果很漂亮： [Cleanup] Successfully deleted 521604 old user notifications 刪除了 521,604 筆！只剩下約 2 萬筆近期資料。 但當我打開 DBeaver 檢查時… 207MB？資料都刪了，空間怎麼沒變？ 為什麼會這樣？理解 PostgreSQL 的 MVCC 這不是 bug，而是 PostgreSQL 的設計特性。 DELETE 不是真的刪除 PostgreSQL 使用 MVCC（Multi-Version Concurrency Control） 來處理並發交易。當你執行 DELETE 時，PostgreSQL 不會真的把資料從磁碟上移除，而是： 將該行標記為「已刪除」（稱為 dead tuple） 保留原始資料，直到沒有任何交易需要參照它 新的查詢看不到這些行，但它們仍佔用磁碟空間 為什麼要這樣設計？ 效能考量：標記刪除比實際移除資料快非常多 並發安全：其他正在執行的 transaction 可能還需要看到舊版本 ACID 保證：確保 transaction isolation 不處理會怎樣？ ...

引言：選擇正確的壓縮工具為什麼重要？ 在日常開發與維運工作中，我們經常需要壓縮檔案：備份資料庫、傳輸日誌檔、打包部署映像檔。選擇適當的壓縮工具，可能讓您的備份時間從 10 分鐘縮短到 2 分鐘，或是將 500MB 的檔案壓縮到 50MB。 本文將透過實際測試數據，深入比較常見的 Linux 壓縮工具，幫助您在不同場景下做出最佳選擇。 測試環境： macOS (Apple Silicon M1 Pro, 10 cores) 測試檔案：PostgreSQL 資料庫備份 (174 MB, my_DB_backup.sql) 測試項目：壓縮率、壓縮速度、解壓速度、特殊功能 壓縮工具快速對照表 工具 壓縮率 壓縮速度 解壓速度 多執行緒 加密 最佳場景 gzip ⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ❌ ❌ 通用場景、快速壓縮 pigz ⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ✅ ❌ 大檔案快速壓縮 bzip2 ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐ ❌ ❌ 中等壓縮需求 xz ⭐⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐ ✅ ❌ 最高壓縮率 zstd ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ✅ ❌ 平衡速度與壓縮率 7z ⭐⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐ ✅ ✅ 跨平台、加密需求 tar - - - - ❌ 打包工具（需搭配壓縮） 1. gzip：經典的壓縮工具 簡介 gzip 是 Linux 系統中最常用的壓縮工具，基於 DEFLATE 演算法（LZ77 + Huffman 編碼）。 ...