「資料庫撐不住」不是一個問題，是三個

「我們的資料庫撐不住了，換 NoSQL 吧」——這句話最大的問題不是答案錯，是問題還沒被定義。「撐不住」至少是三種完全不同的痛，處方也完全不同。

真正的痛點	症狀長什麼樣	該做的
寫入吞吐不夠	insert 變慢、佇列積壓、寫入逾時	減少索引、批次寫入、按時間分區
磁碟裝不下	容量告警、備份時間爆炸	冷熱分層、時間分區歸檔、壓縮
分析查詢太慢	報表要跑幾十分鐘，但一天只跑幾次	送去 columnar／OLAP，別在 OLTP 表上硬掃

「換一套資料庫」對上面三個，一個都沒有直接解到。

為什麼容易混在一起

因為三者的表面症狀都是「慢」，而且常常同時發生。但它們的處方互相衝突：

寫入吞吐不夠  → 要「減少」索引
分析查詢太慢  → 直覺想「增加」索引（但其實該換佈局）

在同一張表上同時追這兩個目標，就是互相抵銷——見 索引是拿寫入換查詢，寫多讀少的表加索引是純虧。

先問的三個問題

1. 這些資料要不要被拿出來用？ 只寫不讀 → 完全不同的處方。
2. 如果要讀，是「拿一整筆」還是「掃一個欄位」？ 前者是 OLTP，後者是 OLAP。
3. 現在的瓶頸量過了嗎？ 沒量過就換資料庫，是拿最貴的一步當第一步。

第三點就是 反正規化要排在索引與物化視圖後面 的順序：先量、再索引、再讀模型，最後才動資料結構——而「換資料庫」比反正規化還要後面。

一句話

大多數「關聯式資料庫撐不住」的現場，死在沒有把問題拆開，不是死在關聯式模型。