上億級別資料庫查詢

一。分割槽

建立年表和分割槽：

分割槽方案

分割槽表是由多個相關的底層表實現，這些底層表也是由控制程式碼物件表示，所以我們也可以直接訪問各個分割槽，儲存引擎管理分割槽的各個底層表和管理普通表一樣（所有的底層表都必須使用相同的儲存引擎），分割槽表的索引只是在各個底層表上各自加上一個相同的索引，從儲存引擎的角度來看，底層表和一個普通表沒有任何不同，儲存引擎也無須知道這是一個普通表還是一個分割槽表的一部分。這個方案也不錯，它對使用者遮蔽了sharding的細節，即使查詢條件沒有sharding column，它也能正常工作（只是這時候效能一般）。不過它的缺點很明顯：很多的資源都受到單機的限制，例如連線數，網路吞吐等。如何進行分割槽，在實際應用中是一個非常關鍵的要素之一。在我們的專案中，以客戶資訊為例，客戶資料量5000萬加，專案背景要求儲存客戶的銀行卡繫結關係，客戶的證件繫結關係，以及客戶繫結的業務資訊。此業務背景下，該如何設計資料庫呢。專案一期的時候，我們建立了一張客戶業務繫結關係表，裡面冗餘了每一位客戶繫結的業務資訊。基本結構大致如下：

二。分庫分表

如何進行分庫分表，目前網際網路上有許多的版本，比較知名的一些方案：

• 阿里的TDDL，DRDS和cobar，
• 京東金融的sharding-jdbc；
• 間組織的MyCAT；
• 360的Atlas；
• 美團的zebra；
• 其他比如網易、58、京東等公司都有自研的 。

但是這麼多的分庫分表中介軟體方案，歸總起來，就兩類：client模式和proxy模式。

三。選擇建立索引

三。sql最佳化

推薦閱讀:

https://blog.csdn.net/rongtaoup/article/details/82457544