網站平台架構演變史（三）-資料庫表的查詢優化

上篇說道了資料庫讀寫分離，對於大型網站來說這麼說是十分有必要的。資料庫在整個互聯網架構中擔當的角色無法有兩個，存儲和運算，很多時候這兩個是並存的，但是在後期，對於上億條數據來說，讓資料庫既要存儲，又要運算，那麼是這是不可行的，為了保證性能，我們僅僅只需要最大化利用DB的存數就行了，連資料庫之間的外鍵管理都不需要，只要有對應的id即可。那麼既然如此，相互關聯的表肯定會存在刪除業務，而事實上我們如今處理刪除操作並不是真正的刪除，只不過我們添加了is_delete這個欄位來標註邏輯是否刪除即可。不然在表關聯的時候可能會查詢不到對應的數據。

如下最重要的用戶表中的記錄就是絕對不能刪除的

舉個栗子，我們辦理信用卡後會有對應銀行中的一個賬戶，就算你不用卡了，銷卡註銷了，那麼你的賬戶記錄還是會存在的，只不過標誌位更改了而已。曾經我有張工行的信用卡，後來不用了，於是在我註銷的第二個月我還款錯了，但是沒有提醒我此卡已經註銷，還是照樣把錢打了進去，於是就只能很麻煩的跑到總行去走流程把錢取出來了。。。

（註：有些表中的記錄可以直接刪除的，比如無所謂的消息表，公告表，這些數據在過期後是不會用到的，那麼刪了也無所謂）

大數據量的情況下查詢怎麼做？

這裡舉兩個栗子：

1、商品表，我們在電商平台查詢商品的時候，其後台並沒有真正的去資料庫查詢，比如淘寶的店鋪就有上千萬家甚至更多，每家店鋪發布的商品又是數以萬計，那麼商品表中的數據就十分龐大了，直接查詢肯定會受到性能影響，那麼這個時候不論做水平拆分還是垂直拆分，最終要做的就是使用搜索引擎技術，比如solr或者ES，這樣每次查詢的時候都是去文件系統中找對應的索引，這樣效率會十分高，商品表對於讀寫來說，寫明顯要比讀要來的多，那麼在這種情況下使用搜索引擎是理想的。

2、交易記錄表，對於交易來說，每天的交易量也會很多，這個時候很大的情況下會進行數據遷移，也就是水平分表，參照京東的設計，在查詢交易的時候把時間分為了多個維度，也就是查詢的時候其實是進行了不同表之間的查詢，這樣可以加速了查詢效率。只不過要設定某一時間要進行不同表之間的數據同步以及切換

總結，查詢效率的提示本質上是縮小查詢範圍，範圍小了，效率就上去了。水平拆分以及垂直拆分要根據實際情況的業務來進行，不能隨意。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！