背景：最近臨近春節業務高峰，另外也快到年底封板期了，各業務都趕在封板前及時發佈功能或者活動，導致公司發佈系統數據庫壓力驟顯。
這不，昨天我們的發佈系統數據庫面臨較大壓力，CPU，活動連接數，慢查詢等都有較大上漲，另外發佈系統後臺數據庫網絡帶寬壓力突破了這套RDS實例配置的極值，該實例的底層資源規格的帶寬基礎限制是5G，最高能到10G，有個突發積分的概念，耗盡以後就被限制到基礎帶寬了，所以會看到網絡帶寬會突破600MByte後忽高忽低的現象。
CPU，活動連接數都明顯上漲
網絡帶寬達到極值後被限流
其實，這個庫表裡存儲的是各應用包管理數據，但是由於這些數據被定義為text類型，而且字段值又比較長，算是大字段類型，一條記錄有幾十KB，還有幾十MB的，應用發佈會頻繁進行這些數據的存儲和查詢，產生大量的網絡和IO交互，從而達到數據庫的帶寬極限，其實這個庫之前業務高峰期出行過一次問題，當時通過升配來解決了，沒多久這次又出現了，沒有從根本上解決問題。
這就是典型的業務研發沒有合適使用數據庫的案例，業務研發常常隻管實現，不管整個架構的安全、穩定性等其他後期的運維管理問題。首先這麼大的數據頻繁存取肯定是不對的，架構上要優化，能加緩存的必須加緩存。另外數據庫也不能簡單的隻提供一個主庫給業務進行增刪改查，可以考慮提供隻讀從庫或者讀寫分離架構來保障穩定性。
各位研發同學都幹過哪些事情，曾經把數據庫打爆了的情況？