鐵律一：圖片、文件、二進制大對象（BLOB）
雖然 MySQL 支持 BLOB/TEXT 類型，但將文件直接存入數據庫是反模式：
- 讀寫性能遠遜於文件系統：數據庫層級的 IO、緩存、權限校驗等開銷巨大。
- 備份災難：備份文件膨脹，耗時指數級增長，恢復極慢。
- 訪問鏈路冗長：每次訪問需穿越應用層→數據庫層→文件系統，無法利用 Nginx/CDN 等靜態資源加速能力。
正解：數據庫僅存儲文件的相對路徑、對象存儲 Key（如 S3/OSS）或 CDN URL。縮略圖同理，別斷送了靜態服務器的性能優勢。
鐵律二：短生命期數據
統計計數、埋點數據、GPS 軌跡、Session、臨時驗證碼……生命週期從幾分鐘到幾周，特徵是「寫多讀少、時效性強、結構簡單、批量過期」。
若發現自己在寫定時任務定期 DELETE FROM ... WHERE create_time < NOW() - INTERVAL 1 HOUR，說明選型錯了！
正解：
- 高頻計數/統計：Redis、StatsD + Graphite
- 時序數據（GPS、監控指標）：InfluxDB、TimescaleDB、Prometheus
- Session/緩存：Redis、Memcached
- 文檔/非結構化臨時數據：MongoDB、Riak
選對工具，事半功倍；用挖掘機種土豆，累且慢。
鐵律三：日志文件
將業務日志存入 MySQL 看似方便查詢，實則隱患巨大：
- 寫入風暴：即使每請求僅 1 條日志，高併發下也是海量
INSERT，搶佔核心業務的數據庫資源（連接、IO、鎖、緩存）。
- 級別失控：一旦開啟
DEBUG/VERBOSE 級別，數據庫瞬間「著火」。
- 污染核心數據：日志與核心業務數據共用實例，故障域未隔離。
正解：
- 結構化日志：ELK Stack (Elasticsearch + Logstash + Kibana)、Splunk、Loggly
- 非結構化/低成本：純文本文件 + 日志輪轉 + 定期歸檔對象存儲
- 查詢分析：離線導入 ClickHouse、Apache Doris 等 OLAP 引擎
雖然查看、分析稍繁瑣，但保護了核心數據庫穩定，總體收益遠大於成本。
總結
MySQL 擅長關係型業務核心數據的事務性存儲與複雜查詢。專注核心職責，將非結構化、高頻時效性、海量寫入場景交給專業組件，是架構演進的必修課。
