之前我們講過利用數(shù)據(jù)庫的讀寫分離提升數(shù)據(jù)庫的讀寫性能，今天我們?cè)賮砹囊涣臄?shù)據(jù)庫優(yōu)化的另外一個(gè)重量級(jí)武器，分庫分表。
我們先來想想這樣的一個(gè)業(yè)務(wù)場(chǎng)景，我們有一個(gè)數(shù)據(jù)庫，存放著用戶的訂單數(shù)據(jù)，隨著我們的業(yè)務(wù)的發(fā)展，訂單的數(shù)據(jù)越來越多，由此會(huì)引來一系列的問題。
首先，單庫的數(shù)據(jù)量會(huì)變得越來越大，占據(jù)大量的磁盤空間，在進(jìn)行數(shù)據(jù)遷移、備份、恢復(fù)所需要的時(shí)間都會(huì)越來越長(zhǎng)。
其次，系統(tǒng)的容災(zāi)性將變差，沒有萬無一失的系統(tǒng)，也沒有萬無一失的機(jī)器，更沒有萬無一失的運(yùn)維工程師與程序員，一旦我們的數(shù)據(jù)庫遭遇到破壞，將會(huì)牽連所有的業(yè)務(wù)與用戶。
最后，是系統(tǒng)的性能會(huì)大大降低，讀寫速度會(huì)變慢，即便是我們使用了索引，也會(huì)發(fā)現(xiàn)讀寫的速度越來越慢，這是為什么呢？有兩個(gè)主要的原因，一是隨著數(shù)據(jù)量的增多，掃描數(shù)也會(huì)增多，一旦我們的索引不合理，或者沒有命中索引，將帶來災(zāi)難性的結(jié)果，另外一個(gè)重要的原因，是索引會(huì)變得越來越大，每次變更索引的變更也會(huì)消耗時(shí)間，并且可能因?yàn)樗饕^大，無法直接存放在內(nèi)存，每次都需要從磁盤中加載索引，造成速度變慢。
從另外一個(gè)角度看，單臺(tái)機(jī)器的性能都是有限的，即便我們可以使用多個(gè)從庫，但也會(huì)造成數(shù)據(jù)的冗余與浪費(fèi)。分庫分表，可以幫我們非常好的解決這個(gè)問題。分庫分表，顧名思義，就是把數(shù)據(jù)分散存儲(chǔ)在不同的數(shù)據(jù)庫與數(shù)據(jù)表中。我們有兩種常見的分庫分表方法：
垂直切分，垂直切分，既按照不同的功能，將不同業(yè)務(wù)的數(shù)據(jù)，存放到不同的數(shù)據(jù)庫中，我們?nèi)匀灰噪娚滔到y(tǒng)為例，我們可以將用戶性別、收貨地址、賬號(hào)等存放在用戶庫中，將商品的圖片、描述、詳情存放在商品數(shù)據(jù)庫中，將用戶的訂單數(shù)據(jù)存放在交易數(shù)據(jù)庫中，不同的數(shù)據(jù)庫之間可以互相隔離，互補(bǔ)影響，這樣子，可以做到一方出故障的時(shí)候，對(duì)其他影響最小。
水平切分，水平切分，即同一個(gè)功能按照一定的維度切割，將他們放到不同的表中。我以阿里巴巴的淘寶天貓數(shù)據(jù)為例，不同用戶之間的交易數(shù)據(jù)，一般都是不互通的，也少有需要跨表查詢場(chǎng)景，于是可以用戶的ID哈希，將其分布在不同的數(shù)據(jù)庫數(shù)據(jù)表中，商品的數(shù)據(jù)，最常見的場(chǎng)景，便是一個(gè)店鋪下所有的商品，我們極少需要跨店鋪去查詢商品的數(shù)據(jù)（搜索頁、推薦頁等的不算，這種場(chǎng)景一般也不是走數(shù)據(jù)庫查詢），所以通常是以商家ID進(jìn)行分表的。
通過分庫分表，我們可以讓數(shù)據(jù)庫每一張表的數(shù)據(jù)都比較可控，從而提高數(shù)據(jù)庫的效率。當(dāng)然，分庫分表也并非十全十美，也會(huì)帶來一些問題，例如，在某些業(yè)務(wù)場(chǎng)景，我們可能需要查詢跨表的數(shù)據(jù)，將會(huì)變得非常麻煩。同時(shí)，如果數(shù)據(jù)庫需要一些連接操作，也會(huì)變得箱單麻煩。想要知道如何解決這些問題的么？歡迎大家關(guān)注我，共同學(xué)習(xí)，共同進(jìn)步。大家的支持是我繼續(xù)嘮嗑的動(dòng)力。同名公眾號(hào)（沙茶敏碎碎念）
