資料開始變大後，系統架構會遇到哪些問題？

大多數系統在早期跑起來都很順。一台主機、一個資料庫、幾千筆資料，查詢快、部署簡單、沒什麼要擔心的。

然後資料開始積累。幾萬筆、幾十萬筆、幾百萬筆。某天開始，報表跑得很慢。API 回應時間從 200 毫秒變成兩秒。備份要跑三個小時。

這些問題是怎麼來的，又有哪些方向可以處理？

第一個壓力點：資料庫查詢開始變慢

資料少的時候，資料庫掃全表也很快，感覺不出來。資料多了，同樣的查詢可能要跑好幾秒——因為它在幾百萬行裡一行一行找你要的東西。

索引（Index） 是最直接的解法。索引就像書的目錄，告訴資料庫「如果要找這個欄位的值，不用從頭掃，去這裡找」。加了索引，查詢速度可以從秒級降到毫秒級。

但索引不是免費的。每次新增或更新資料，索引也需要同步更新。索引加太多，寫入效能反而下降。判斷哪些欄位需要索引，需要分析實際的查詢模式，不是無腦全加。

另一個常用的手段是 查詢優化。很多慢查詢不是資料量的問題，而是 SQL 寫得低效——用了 SELECT * 撈出一堆不需要的欄位、做了不必要的 JOIN、沒有利用已有的索引。用資料庫的 EXPLAIN 指令分析查詢執行計畫，通常能找到明顯的改善點。

很多系統的讀和寫壓力不對稱。電商的商品列表、報表查詢，讀的頻率遠高於寫。如果讀寫都壓在同一個資料庫上，讀的量大了，寫入的延遲也跟著上升。

讀寫分離 的做法是設立一個主資料庫（Master）負責寫入，同步多個從資料庫（Replica）負責讀取。寫進主資料庫的資料，自動複製到從庫；讀取的請求分散到從庫上。

這個架構讓讀和寫可以獨立擴展，讀取壓力大就多加幾個 Replica，不影響寫入效能。

有些資料被反覆讀取，但很少改變——熱門商品列表、用戶基本資料、系統設定。每次讀取都打資料庫，是不必要的消耗。

快取（Cache） 把這些常用資料存在記憶體裡（通常用 Redis 或 Memcached），讀取的時候先查快取，快取命中就直接回傳，不需要碰資料庫。

快取的引入讓系統能夠用少量資料庫資源服務大量的讀取請求，但也帶來了快取一致性的問題：資料庫更新了，快取裡的舊資料要怎麼處理？設計快取失效策略是這個架構的核心挑戰。

資料庫效能是一個面向，儲存空間是另一個。

歷史記錄、操作日誌、舊版資料，這些資料隨時間累積，佔用大量空間，但大多數時候不需要被查詢。把它們跟活躍資料存在一起，資料庫的體積不斷膨脹，備份時間變長，成本升高。

冷熱資料分離 是常見的處理方式。近三個月的訂單是熱資料，留在主資料庫；三個月以前的訂單是冷資料，搬到成本較低的歸檔儲存（或雲端物件儲存如 GCS、S3）。需要查歷史資料的情況有，但不常，這樣的分離讓主資料庫保持精簡。

檔案類的儲存更需要獨立處理。合約、圖片、影片這類二進位檔案，不應該塞進關聯式資料庫，而是存在物件儲存服務裡，資料庫只存路徑。

系統初期，備份可能五分鐘跑完，不是問題。資料量大了，完整備份可能要好幾個小時，備份期間對資料庫的 I/O 壓力也會影響正常服務。

增量備份 是解法之一——每次只備份上次備份之後有變化的資料，而不是每次都完整備份。這大幅縮短備份時間，代價是還原時需要組合多個備份檔案，流程稍微複雜。

另一個做法是利用 Replica 進行備份，讓備份操作打在從庫上，不影響主庫的正常讀寫。

上面說的這些問題，有一個共同點：它們都是慢慢發展的，不是突然從好到壞。

如果系統沒有監控，你不會知道資料庫的查詢時間在過去三個月每個月都在變長，直到哪天超過閾值，用戶開始抱怨。

建立監控——查詢慢的記錄在 Slow Query Log、磁碟用量超過 70% 告警、API 回應時間 P99 超標告警——讓你在問題還小的時候就看到它，而不是等它變成緊急事件。

資料量增長是系統成熟的自然結果，不是出了什麼問題。出問題的是沒有提前規劃讓架構跟上資料的成長速度。