三類資料絕不可存入 MySQL：圖片/文件、短期資料、日誌

雖然 MySQL 支援 BLOB/TEXT 類型，但將特定類型資料直接存入資料庫往往是架構反模式。本文剖析三類「禁忌資料」的危害與正確替代方案。

一、圖片、文件、二進制大物件 (BLOB)

❌ 錯誤做法

CREATE TABLE documents (
    id INT PRIMARY KEY,
    file_content LONGBLOB  -- 直接存 PDF、圖片、Word
);

🚨 核心危害

1. 讀寫效能遠低於檔案系統：資料庫層級的緩衝池、事務日誌、鎖機制對大流量串流讀寫無優勢
2. 備份體積暴增：幾 GB 資料庫變幾百 GB，備份/恢復時間呈指數級增長，影響 RTO/RPO
3. 存取路徑冗長：Client → App Server → DB Server → Storage，中間多兩層網路跳轉與協議解析
4. 失去 CDN/靜態伺服器加速：無法直接使用 Nginx、CloudFront、OSS 等邊緣緩存分發

✅ 正確架構

CREATE TABLE documents (
    id INT PRIMARY KEY,
    file_path VARCHAR(500) NOT NULL,  -- 相對路徑或 S3 Key
    file_size BIGINT,
    mime_type VARCHAR(100),
    storage_type ENUM('local','s3','oss') DEFAULT 's3'
);

• 檔案存：本地磁碟 / NFS / MinIO / AWS S3 / 阿里云 OSS
• 資料庫僅存元數據 + 存儲路徑
• 縮圖同理，交由圖片處理服務 (ImageMagick、Thumbor) 生成並存儲

二、短生命週期資料 (統計、遙測、Session、GPS 軌跡)

❌ 錯誤做法

建立資料表，寫入後用 cron 定時 DELETE WHERE created_at < NOW() - INTERVAL 1 HOUR 清理。

🚨 核心危害

1. 寫入放大：高頻 INSERT 產生大量 undo log、binlog、checkpoint 壓力
2. 刪除碎片化：大量 DELETE 留下空洞，需 OPTIMIZE TABLE 整理，鎖表風險高
3. 索引膨脹：時間序列資料索引持續增大，緩衝池命中率下降
4. 工具錯位：用挖土機種馬鈴薯——關係型資料庫非為時間序列/高寫入/自動過期設計

✅ 專用替代方案

三、應用日誌 (Access Log、Error Log、Audit Log、Debug Log)

❌ 錯誤做法

CREATE TABLE app_logs (
    id BIGINT AUTO_INCREMENT,
    level VARCHAR(10),
    message TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

🚨 核心危害

1. 爭搶業務資源：每秒成千上萬 INSERT 搶佔連線、鎖、緩衝池、磁碟 IO，影響核心交易效能
2. Verbose/Debug 級別觸發雪崩：問題排查時開啟詳細日誌，寫入量暴增 10-100 倍，直接拖垮主庫
3. 查詢分析困難：SQL 不擅長全文搜尋、多維度聚合、即時儀表板
4. 備份污染：日誌資料無業務價值卻佔用備份空間與時間

✅ 正確架構：日誌管道分離

Application → Stdout/Filebeat/Fluentd → Kafka/Logstash → Elasticsearch/Splunk/Datadog/Loki
                    ↓
              Local rotating files (fallback)

• 結構化日誌：JSON 格式，包含 trace_id、span_id、環境標籤
• 分級存儲：熱資料 (7-30 天) 進 ES/Loki 即時查詢；冷資料進 S3/HDFS 歸檔合規
• 應急查詢：保留本地輪轉檔案 (logrotate) 作為最後手段

總結：選對工具，事半功倍

資料庫擅長：關聯查詢、ACID 事務、結構化業務資料
資料庫不擅長：大二進制、高頻時間序列、非結構化日誌、臨時快取

「用挖土機在後花園種馬鈴薯雖然可行，但拿把鏟子更快、更省油、不傷草皮。」