引言

2023年8月27日，隨著新業務的接入，我們開始進行項目的灰度發佈。然而，直到2023年8月31日下午，我們才發現一個新欄位並沒有進行欄位刷新，導致所有數據都是預設值，從而無法繼續進行灰度測試。在業務方的要求下，我們需要進行批量更新欄位。鑒於我們已經知道了時間範圍，我們決定在白天進行批量更新數據。正是在這個過程中，故障發生了！

系統簡介

該系統是一個服務群，其請求量主要集中在工作時間（9點-17點），大約有110萬個請求。此外，系統還有各種定時任務和批處理任務。其中，涉及本次更新表的服務集群在工作時間其請求量約為90萬個，這表明該服務是服務群中的核心請求服務。

然而，整個系統只有一個後臺資料庫，並且採用的是主從架構。遺憾的是，並沒有實現讀寫分離。從庫僅用作備份和應急資料庫處理。

時間線

1. 8月31日下午13點50分，運維人員根據時間點執行了查詢語句，查詢了即將要更新的數據量為200萬行。其中，dateCol欄位是一個獨立的時間索引。
2. 8月31日下午16點0分，運維人員使用資料庫工具執行了更新單表數據的操作，並未查看執行計劃。SQL語句如下：update table set newCol = oldCol where dateCol >= 時間點；
3. 8月31日下午16點8分，在更新操作執行了8分鐘後，運維人員意識到存在問題，點擊了資料庫工具上的取消按鈕，想要終止更新操作。
4. 8月31日下午16點16分，在取消操作成功之間的經過了8分鐘，業務請求開始超時，整個資料庫陷入癱瘓狀態。儘管最後取消更新操作顯示為成功，但資料庫仍然無法正常運行。
5. 8月31日下午16點30分，緊急關停了所有服務，開始切換資料庫，並查看相關資料庫執行日誌。
6. 8月31日下午17點，資料庫切換工作完成，所有服務正常啟動。通過查看執行日誌，發現問題出在運維人員執行的更新語句上。而且執行計劃顯示該語句並未命中時間索引。

問題分析

時間索引

我們先來看下時間索引，時間索引是資料庫中一種常見的索引類型，用於加速針對時間列的查詢操作。它的特點包括：

• 有序性：時間索引按照時間的順序進行排序，使得查詢根據時間範圍進行過濾更加高效。
• 快速定位：時間索引通過使用B樹或B+樹等數據結構，使得資料庫可以快速定位到指定時間點或時間範圍的數據。
• 支持時間範圍查詢：時間索引可以用於查詢滿足特定時間範圍的數據，如查詢某一天、某一周或某一月的數據。
• 支持時間序列分析：時間索引可以用於時間序列數據的分析與聚合操作，如計算某一時間段內的平均值、總和等。

然而，時間索引也存在失效的場景，包括但不限於：

• 索引列數據分佈不均勻：如果時間列的取值分佈不均勻，例如某些時間段的數據較多，而其他時間段的數據較少，那麼時間索引的效果可能會大打折扣，導致查詢性能下降。
• 大量更新操作：當有大量的數據更新操作（如插入、更新、刪除）發生時，時間索引的維護成本較高，可能導致索引失效或性能下降。
• 跨時間段查詢：如果查詢涉及到多個時間段的數據，時間索引可能無法有效利用，需要進行全表掃描，影響查詢性能。

問題點

根據整個流程，我們可以思考一下存在哪些不當之處。我已經考慮了以下幾個問題點：

1. 執行時間不當：在正常的月末業務月結期間，資料庫請求量非常大，批量數據的更新應該在晚上進行，而不是在下午這個關鍵時間點。這樣可以避免對系統的正常運行造成干擾。
2. 操作流程不當：按照公司規定，在執行更新語句之前，至少需要兩個人同時查看，確保沒有資料庫問題才能進行執行。然而，在這次更新中只有一個人進行了操作，違反了公司的規定。這樣的做法可能增加了潛在的風險。
3. 缺乏執行計劃：在執行更新操作之前，用戶沒有查看執行計劃，無法得知時間索引是否已經失效了，該更新語句是否會導致全鎖。缺乏對執行計劃的瞭解可能會導致性能問題或者不必要的資源浪費。
4. 缺乏限流機制：系統中缺乏引入限流工具，當資料庫壓力劇增時，大量請求同時訪問資料庫，這會增加資料庫的負載壓力。引入限流機制可以有效降低資料庫的訪問量，避免過載導致的性能問題。

經驗總結

根據以上問題點，我總結了一下可以改進的建議：

1. 確認資料庫的更新時間：根據業務的風險級別，安排合適的批量更新操作時間。
2. 優化更新操作：通過查看執行計劃，針對性地優化更新語句，避免全鎖的情況發生。並不是修改成分批更新就行了，可能在更新7月的數據還是可以命中時間索引的，但是在更新8月份的時候就失效了，所以只要條件發生變更就需要重新查看執行計劃。
3. 使用限流工具：在系統中引入限流工具，如Sentinel，對請求進行限流，避免大量請求同時訪問資料庫。可以設置合理的流量控制策略，防止資料庫被過多的請求壓力影響性能。
4. 設置超時時間和重試機制：對業務請求設置合理的超時時間和重試機制，當請求超時時及時進行重試或返回錯誤信息，避免請求一直處於等待狀態。可以通過配置合理的超時時間和實現自動重試機制，提高系統的穩定性和響應能力。
5. 調整資料庫參數：根據實際情況，調整資料庫的參數，如連接池大小、最大連接數等，以提高資料庫的性能和穩定性。
6. 定期維護和優化資料庫：定期進行資料庫的維護和優化工作，如清理無用數據、重建索引等，以保持資料庫的良好狀態。可以定期進行數據清理和歸檔，優化數據表結構和索引，提升資料庫的查詢和更新效率，以保持資料庫的良好狀態。就比如我們這張表盡然存在著5年前的數據，而業務最多可能會涉及最近2年的數據量，對於長時間未使用的數據，可以將其遷移到另一張表或者進行冷熱數據分離，以減少單張數據表的數據量。

總結

在這次操作不當導致資料庫癱瘓的故障中，我們發現了幾個問題點：執行時間不當、操作流程不當、缺乏執行計劃和限流機制。針對這些問題，我們提出了改進建議：確認資料庫更新時間、優化更新操作、使用限流工具、設置超時時間和重試機制、調整資料庫參數以及定期維護和優化資料庫。通過這次故障的經驗分享，我們應該引以為戒，加強對操作的謹慎性和規範性，以確保系統的穩定運行。