分庫：
1、數據庫分庫而不是分表，分表需要考慮后期的查詢問題，此外還需要注意分表的算法（哈希算法）。
2、熱數據只占全部數據的一部分，因此每次優先查詢熱庫，以下情況才查詢冷庫
- 當查詢條件未命中（結果集為空）時，查詢冷庫。
- 當查詢條件部分命中時，查詢冷庫。
3、為了區分部分命中和全部命中，可以在熱庫中建一張R表存放每次查詢冷庫的查詢條件和查詢結果數量和查詢結果的主鍵，每次查詢熱庫時，對比相同查詢條件的查詢結果數量是否一致。一致，則本次查詢結束。不一致，則需要到冷庫中進行查詢。
4、更優方案：不一致的情況，只到冷庫中查詢未查到的數據。此時R表需要存放的不僅是查詢結果數量，還有查詢結果的所有主鍵。
5、舉例說明：100條中80條還是熱數據 20條變成了冷數據，其實應該只是對冷數據庫發起這20條數據的請求。此時需要將R表數據拿出來比對，只查一部分冷數據。
6、熱庫=>冷庫 : 查詢和使用熱數據時，將一段時間不再使用的熱數據移到冷庫。
7、冷庫=>熱庫 ：查詢冷庫時，將本次查詢的結果移到熱庫，附上最新查詢日期。
8、數據同步（每次查詢進行或達到一定量級進行）
9、關於命中的處理：制定查詢條件字典 如 where a=? and b=? 這個條件的字典為
public static IDictionary<int,int> QueryKeyValues=new IDictionary<int,int>{
(0,1),(1,2),(3,3)
}
先進行查詢條件的字典命中處理=> 假設此時的查詢方法為 queryFunction(int a,int b)
queryFunction(int a,int b) {}
public object QueryFunction(int a,int b) {
1.若 <a,b> 存在於 QueryKeyValues中則到R表中找出查詢條件為<a,b>的IdString都有哪些 以此將Id分開存取
2.獲得IdString后 比對需要到冷庫查詢的List<string> singleId
3.循環執行單條語句查詢邏輯 SingleColdDBQuery(List<string> singleId)
}
分表：
舉個簡單的例子，按數據的新舊分表
eg：比如我現在有一個訂單表，日均寫入幾萬幾十萬數據進去，可以這樣處理，存儲數據的時候存儲雙份，order表存一份數據，order_history表同樣也存一份數據，然后呢，order表弄一個定時任務，每天定期刪除30天以上的數據（一般半夜刪數據），一天無非幾萬條數據，性能影響幾乎沒有，不過量多的話，刪除就要小心點，不然很容易就鎖表，可以查一下一個月前的數據的區間范圍（表的主鍵id范圍），然后呢按區間刪除，幾千幾千的刪除（可以自行調節，保證 IOPS跟CUP別跑滿就行），這樣就能保證不會鎖表；order_history表不做任何刪除操作，只插入新的數據，保留最原始的數據。
說一下表的查詢，一個月以內的數據直接在order表查詢就行，一個月以上的舊數據在history表查，order_history表的查詢可以配合搜索引擎進行處理（比如阿里雲的opensearch），每次查出對應的主鍵id（節省opensearch的流量，要錢的！），然后再去order_history根據主鍵查數據，這里底層封裝好就行