查詢優化主要涉及到兩塊。
1.訂單表數據查詢優化
訂單數據庫是單獨出來的，每一條記錄記錄顯示都涉及到用戶名稱(微信號，昵稱，app昵稱)，商家名稱(商家名稱，電話)，設備名稱(設備編號，車牌號)等。
按照目前的表設計，訂單庫和用戶庫，商家庫，設備庫都獨立，表都是通過主鍵ID進行關聯，訂單表存放的是，，等。這種設計方式帶來一個瓶頸，就是訂單記錄顯示的時候要通過ID關聯查詢顯示出用戶我的訂單詳情查詢，商家，設備的信息并展示在前端頁面。當初在開發過程中，由于時間比較趕，沒有做過多的細節優化，都是通過后臺訂單微服務通過ID去循環查詢去用戶，商家以及設備的信息再到前端展示，剛開始還好，畢竟每頁只顯示10條數據，打開頁面過程中3秒左右。后面頁面調整到顯示20條，結果打開這個頁面訂單微服務偶爾報超時現象。為了解決超時這個問題，將數據組裝放到前端，由前端根據ID再請求具體的用戶，商家，設備微服務展示相關信息，雖然解決了微服務超時問題，但是前端每次訪問頁面出現了大量的ajax請求我的訂單詳情查詢，對前端性能造成非常大的體驗影響。也曾經和業務有溝通過，就是這個訂單頁面顯示的時候能不能不顯示用戶，商家，設備的信息，只顯示訂單記錄相關，然后通過點訂單詳情進入詳情頁面再顯示用戶，商家，設備信息，但是業務這塊產品體驗又不太好，所以還是得想辦法解決這個問題。其實這塊訂單表當初設計的時候太過于追求數據庫的設計范式，導致查詢起來關聯的太多，其實訂單表設計要考慮到第一時間的呈現方式，經過后面優化，其實最簡單的方案就是在訂單表冗余幾個相關字段，用戶名稱，商家名稱，設備名稱即可。可能還涉及到一個數據更新的問題，一般的業務場景主鍵ID不可修改這個是肯定的，但是有些可以修改用戶名稱什么的，這個時候可能需要同步更新到訂單表的那些冗余字段信息，注意這點就可以。
2.大數據單表多條件查詢優化
訂單是按月物理分表的，如，，等，查詢條件上的查詢時間也是控制了只能選擇當月的第1天到當月最后一天，隨著平臺的業務量越來越大，現在又出現一個問題，當選擇的查詢條件過多，然后選擇的時間區間較大比如選擇1號到30號，結果查詢速度巨慢等很久才出來結果，甚至也會出現查詢異常超時現象。問題引起原因我們也清楚，是一個月的訂單數據量太大，查詢條件過多，區間過大，然后表又做全局掃描，所以導致慢和超時現象，這塊要繼續優化方案目前有二種。第一種是將月份表繼續分表，比如按周，甚至按天盡量壓縮查詢的倉庫。第二種是限制查詢的時間區間，比如每次只能查三天的數據或者更小。另外查詢條件較多的情況下要做聯合索引(組合索引)。目前我們用最快的時間的時間解決暫時先限制查詢的時間區間。
另外提下，數據庫架構表設計其實和產品設計都密不可分，雙方一定要結合起來做設計，有時候產品細節設計要傾向于數據庫表設計。
免責聲明：部分文章信息來源于網絡以及網友投稿，本站只負責對文章進行整理、排版、編輯，出于傳遞更多信息之目的，并不意味著贊同其觀點或證實其內容的真實性，如本站文章和轉稿涉及版權等問題，請作者在及時聯系本站，我們會盡快為您處理。
