之前在BAT里參與過一個公司級應用（非市場級，投入的人力也不會那么大），上線2年后，總是被用戶投訴，原因是這個應用使用MySql數據庫來做持久層，但是2年了，有一張非常重要的存儲歷史任務的表實在是太大了，導致通過頁面想要查詢歷史數據的速度變得非常非常慢，所以用戶很是不滿意。

分析下來，這不是用Redis能解決的緩存問題，而是歷史數據的查詢響應速度問題。

我們最開始是希望能夠通過增加索引的方式解決，但是面對千萬級別的數據量，我們也不敢貿然加索引，因為一旦數據庫hang住，期間的所有數據庫寫入請求都會被放到等待隊列中，如果請求是通過http請求發過來的，很有可能導致服務發生分鐘級別的超時不響應。

雖然經常被用戶投訴反應慢，也不能破罐破摔，直接超時不響應了吧。

于是我們陷入了兩難的境地。

后來我們分了兩個部分來優化持久層。

MySQL的主從配置

第一步就是配置MySQL的主從庫，通過將讀寫請求分離，來提高數據庫的響應速度。

從上圖可知，來自同一臺服務器的請求，經過MySQL-proxy被分流給了不同的MySQL節點，其中寫請求給了主節點，讀請求給了從節點。因此，我們首先通過分流的方式，減輕了單節點MySQL的響應壓力，實現了優化的第一步。

引入ElasticSearch

但是，只配置MySQL的主從是遠遠不夠的。

通過查閱論壇，相關資料，我們最終敲定在持久層引入ElasticSearch。

ElasticSearch是一個輕量級的持久層工具，它支持動態多節點部署，自動備份，節點掉線后能夠自動切換主從，動態廣播發現新上線的節點，而這些優點的應用，無須修改任何server端配置。可以這樣理解，如果你部署了4個elasticsearch節點，其中2個掉了，服務器還是可以很好的繼續運行。

此外，它還有一個最重要的優勢，那就是支持大數據快速查詢。一張幾千萬的表，如果用MySQL查詢，可能需要幾秒到幾十秒不等，但是如果用elasticsearch，只需要毫秒級別就能查詢到結果。完美的解決了我們當前的問題，還順帶幫我們鞏固了持久層的穩定性問題。

綜上，優化Mysql的目的是為持久層服務，除了引入主從配置，當MySQL自身局限性導致無法繼續優化后，引入其他技術也是十分必要的。

如果你對這篇回答有任何問題，歡迎在下方點贊，留言。

我是蘇蘇思量，來自BAT的java開發工程師，頭像是本人，每天都會分享科技類見聞，我，與我共同進步。