SQL優化之路

原由

APP所需的數據採集大體已經結束，統計了一下數據條數，它是這樣的：

花了大約四分鐘，因而我換了個小規模的數據庫測試了一下查詢：

等了大約秒：

這時候的數據量是多少呢，不到萬條。整體數據條數大約在萬左右。大概算一下從客戶端發出請求到得到返回數據大概須要 分鐘 ，我見到的延遲分鐘的應用大概是這個了。顯然，個人這個數據庫查詢是有問題滴~

---

繼續

那麼問題出在哪裏呢 ？問題可能出如今不少方面。不妨先放下來看一下別人是怎麼實現的。

官方檢索耗時大約兩秒左右，第一個結果的出現說明採起了前綴索引，必然進行了全表掃描了。那麼它的數據規模有多少呢，試一下，大約有 萬條。

如今就發現問題所在了，我獲取的數據有 萬條，可是這裏只有 萬條，那剩下的 萬條去哪裏了？ 你猜對了，每一種書都會有不止一本。隨便點開搜索結果的一本，果真，館藏五本。

到此，官方的實現思路就清晰了。 （2U + 16*8內存 + SSD ）的服務器部署 MYSQL + Spring。數據分表，書目表+書詳情表。查詢的時候先在數據較小的書目表中查詢出書的名稱，書詳情表中對書名創建BTREE索引。這樣足以在用戶能夠接受的時間內完成查詢。

優化思路一

創建書目表和書詳情表，這樣能夠把數據規模縮小 ，帶來的性能提高仍是很可觀的。

果真，此次在萬條數據中查詢用了秒，已經接近官方的數據了。

優化思路二

放棄前綴模糊匹配

這應該已經脫離優化的範疇了，爲了速度而犧牲了數據的準確性。秒的延遲徹底在可接受的範圍以內，可是在數據量巨大的狀況下，有必要進行前綴後綴匹配嗎？以關鍵詞爲例，前綴模糊查詢耗時秒得到條結果，後綴模糊查詢耗時秒得到條結果，相差約條記錄。思考一下app開發的初衷:給用戶推薦更好的書。一本書質量的最終判斷應該交給用戶。所以，將用戶引導至書架更爲重要。因此犧牲一部分準確性是可行的。

優化思路三

刪減部分陳舊的書

仍是以爲例，在模糊匹配的本書中，出現了大量的這種書：

很明顯這一部份書的參考價值已經不大了。以 年爲界， 年的書共有 種，即大約有 的書是冗餘的。那麼數據庫的規模又能夠縮小一部分，剩餘大約28萬種。查詢時間大概能縮小至 秒。

優化思路四

加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢 ！加錢