讀寫分離分散了數(shù)據(jù)庫讀寫操作的壓力剃执，但沒有分散存儲(chǔ)壓力誓禁，當(dāng)數(shù)據(jù)量達(dá)到千萬甚至上億條的時(shí)候，單臺(tái)數(shù)據(jù)庫服務(wù)器的存儲(chǔ)能力會(huì)成為系統(tǒng)的瓶頸肾档，主要體現(xiàn)在這幾個(gè)方面：

數(shù)據(jù)量太大摹恰，讀寫的性能會(huì)下降，即使有索引怒见，索引也會(huì)變得很大俗慈，性能同樣會(huì)下降。

數(shù)據(jù)文件會(huì)變得很大遣耍，數(shù)據(jù)庫備份和恢復(fù)需要耗費(fèi)很長時(shí)間闺阱。

數(shù)據(jù)文件越大，極端情況下丟失數(shù)據(jù)的風(fēng)險(xiǎn)越高（例如舵变，機(jī)房火災(zāi)導(dǎo)致數(shù)據(jù)庫主備機(jī)都發(fā)生故障）酣溃。

基于上述原因，單個(gè)數(shù)據(jù)庫服務(wù)器存儲(chǔ)的數(shù)據(jù)量不能太大纪隙，需要控制在一定的范圍內(nèi)赊豌。為了滿足業(yè)務(wù)數(shù)據(jù)存儲(chǔ)的需求，就需要將存儲(chǔ)分散到多臺(tái)數(shù)據(jù)庫服務(wù)器上绵咱。

今天我來介紹常見的分散存儲(chǔ)的方法“分庫分表”碘饼，其中包括“分庫”和“分表”兩大類。

業(yè)務(wù)分庫

業(yè)務(wù)分庫指的是按照業(yè)務(wù)模塊將數(shù)據(jù)分散到不同的數(shù)據(jù)庫服務(wù)器悲伶。例如艾恼，一個(gè)簡單的電商網(wǎng)站，包括用戶麸锉、商品钠绍、訂單三個(gè)業(yè)務(wù)模塊，我們可以將用戶數(shù)據(jù)花沉、商品數(shù)據(jù)五慈、訂單數(shù)據(jù)分開放到三臺(tái)不同的數(shù)據(jù)庫服務(wù)器上，而不是將所有數(shù)據(jù)都放在一臺(tái)數(shù)據(jù)庫服務(wù)器上主穗。

雖然業(yè)務(wù)分庫能夠分散存儲(chǔ)和訪問壓力，但同時(shí)也帶來了新的問題毙芜，接下來我進(jìn)行詳細(xì)分析忽媒。

1.join 操作問題

業(yè)務(wù)分庫后，原本在同一個(gè)數(shù)據(jù)庫中的表分散到不同數(shù)據(jù)庫中腋粥，導(dǎo)致無法使用 SQL 的 join 查詢晦雨。

例如：“查詢購買了化妝品的用戶中女性用戶的列表”這個(gè)功能架曹，雖然訂單數(shù)據(jù)中有用戶的 ID 信息，但是用戶的性別數(shù)據(jù)在用戶數(shù)據(jù)庫中闹瞧，如果在同一個(gè)庫中绑雄，簡單的 join 查詢就能完成；但現(xiàn)在數(shù)據(jù)分散在兩個(gè)不同的數(shù)據(jù)庫中奥邮，無法做 join 查詢万牺，只能采取先從訂單數(shù)據(jù)庫中查詢購買了化妝品的用戶 ID 列表，然后再到用戶數(shù)據(jù)庫中查詢這批用戶 ID 中的女性用戶列表洽腺，這樣實(shí)現(xiàn)就比簡單的 join 查詢要復(fù)雜一些脚粟。

2. 事務(wù)問題

原本在同一個(gè)數(shù)據(jù)庫中不同的表可以在同一個(gè)事務(wù)中修改，業(yè)務(wù)分庫后蘸朋，表分散到不同的數(shù)據(jù)庫中核无，無法通過事務(wù)統(tǒng)一修改。雖然數(shù)據(jù)庫廠商提供了一些分布式事務(wù)的解決方案（例如藕坯，MySQL 的 XA）团南，但性能實(shí)在太低，與高性能存儲(chǔ)的目標(biāo)是相違背的炼彪。

例如吐根，用戶下訂單的時(shí)候需要扣商品庫存，如果訂單數(shù)據(jù)和商品數(shù)據(jù)在同一個(gè)數(shù)據(jù)庫中霹购，我們可以使用事務(wù)來保證扣減商品庫存和生成訂單的操作要么都成功要么都失敗佑惠，但分庫后就無法使用數(shù)據(jù)庫事務(wù)了，需要業(yè)務(wù)程序自己來模擬實(shí)現(xiàn)事務(wù)的功能齐疙。例如膜楷，先扣商品庫存，扣成功后生成訂單贞奋，如果因?yàn)橛唵螖?shù)據(jù)庫異常導(dǎo)致生成訂單失敗赌厅，業(yè)務(wù)程序又需要將商品庫存加上；而如果因?yàn)闃I(yè)務(wù)程序自己異常導(dǎo)致生成訂單失敗轿塔，則商品庫存就無法恢復(fù)了特愿，需要人工通過日志等方式來手工修復(fù)庫存異常。

3. 成本問題

業(yè)務(wù)分庫同時(shí)也帶來了成本的代價(jià)勾缭，本來 1 臺(tái)服務(wù)器搞定的事情揍障，現(xiàn)在要 3 臺(tái)，如果考慮備份俩由，那就是 2 臺(tái)變成了 6 臺(tái)毒嫡。

基于上述原因，對于小公司初創(chuàng)業(yè)務(wù)幻梯，并不建議一開始就這樣拆分兜畸，主要有幾個(gè)原因：

初創(chuàng)業(yè)務(wù)存在很大的不確定性努释，業(yè)務(wù)不一定能發(fā)展起來，業(yè)務(wù)開始的時(shí)候并沒有真正的存儲(chǔ)和訪問壓力咬摇，業(yè)務(wù)分庫并不能為業(yè)務(wù)帶來價(jià)值伐蒂。

業(yè)務(wù)分庫后，表之間的 join 查詢肛鹏、數(shù)據(jù)庫事務(wù)無法簡單實(shí)現(xiàn)了逸邦。

業(yè)務(wù)分庫后，因?yàn)椴煌臄?shù)據(jù)要讀寫不同的數(shù)據(jù)庫龄坪，代碼中需要增加根據(jù)數(shù)據(jù)類型映射到不同數(shù)據(jù)庫的邏輯昭雌，增加了工作量。而業(yè)務(wù)初創(chuàng)期間最重要的是快速實(shí)現(xiàn)健田、快速驗(yàn)證烛卧，業(yè)務(wù)分庫會(huì)拖慢業(yè)務(wù)節(jié)奏。

有的架構(gòu)師可能會(huì)想：如果業(yè)務(wù)真的發(fā)展很快妓局，豈不是很快就又要進(jìn)行業(yè)務(wù)分庫了总放？那為何不一開始就設(shè)計(jì)好呢？

其實(shí)這個(gè)問題很好回答好爬，按照我前面提到的“架構(gòu)設(shè)計(jì)三原則”局雄，簡單分析一下。

首先存炮，這里的“如果”事實(shí)上發(fā)生的概率比較低炬搭，做 10 個(gè)業(yè)務(wù)有 1 個(gè)業(yè)務(wù)能活下去就很不錯(cuò)了，更何況快速發(fā)展穆桂，和中彩票的概率差不多宫盔。如果我們每個(gè)業(yè)務(wù)上來就按照淘寶、微信的規(guī)模去做架構(gòu)設(shè)計(jì)享完，不但會(huì)累死自己灼芭，還會(huì)害死業(yè)務(wù)。

其次般又，如果業(yè)務(wù)真的發(fā)展很快彼绷，后面進(jìn)行業(yè)務(wù)分庫也不遲。因?yàn)闃I(yè)務(wù)發(fā)展好茴迁，相應(yīng)的資源投入就會(huì)加大寄悯，可以投入更多的人和更多的錢，那業(yè)務(wù)分庫帶來的代碼和業(yè)務(wù)復(fù)雜的問題就可以通過增加人來解決堕义，成本問題也可以通過增加資金來解決热某。

第三，單臺(tái)數(shù)據(jù)庫服務(wù)器的性能其實(shí)也沒有想象的那么弱，一般來說昔馋，單臺(tái)數(shù)據(jù)庫服務(wù)器能夠支撐 10 萬用戶量量級的業(yè)務(wù)，初創(chuàng)業(yè)務(wù)從 0 發(fā)展到 10 萬級用戶糖耸，并不是想象得那么快秘遏。

而對于業(yè)界成熟的大公司來說，由于已經(jīng)有了業(yè)務(wù)分庫的成熟解決方案嘉竟，并且即使是嘗試性的新業(yè)務(wù)邦危，用戶規(guī)模也是海量的，這與前面提到的初創(chuàng)業(yè)務(wù)的小公司有本質(zhì)區(qū)別舍扰，因此最好在業(yè)務(wù)開始設(shè)計(jì)時(shí)就考慮業(yè)務(wù)分庫倦蚪。例如，在淘寶上做一個(gè)新的業(yè)務(wù)边苹，由于已經(jīng)有成熟的數(shù)據(jù)庫解決方案陵且，用戶量也很大，需要在一開始就設(shè)計(jì)業(yè)務(wù)分庫甚至接下來介紹的分表方案个束。

分表

將不同業(yè)務(wù)數(shù)據(jù)分散存儲(chǔ)到不同的數(shù)據(jù)庫服務(wù)器慕购，能夠支撐百萬甚至千萬用戶規(guī)模的業(yè)務(wù)，但如果業(yè)務(wù)繼續(xù)發(fā)展茬底，同一業(yè)務(wù)的單表數(shù)據(jù)也會(huì)達(dá)到單臺(tái)數(shù)據(jù)庫服務(wù)器的處理瓶頸沪悲。例如，淘寶的幾億用戶數(shù)據(jù)阱表，如果全部存放在一臺(tái)數(shù)據(jù)庫服務(wù)器的一張表中殿如，肯定是無法滿足性能要求的，此時(shí)就需要對單表數(shù)據(jù)進(jìn)行拆分最爬。

單表數(shù)據(jù)拆分有兩種方式：垂直分表和水平分表涉馁。示意圖如下：

為了形象地理解垂直拆分和水平拆分的區(qū)別，可以想象你手里拿著一把刀烂叔，面對一個(gè)蛋糕切一刀：

從上往下切就是垂直切分谨胞，因?yàn)榈兜倪\(yùn)行軌跡與蛋糕是垂直的，這樣可以把蛋糕切成高度相等（面積可以相等也可以不相等）的兩部分蒜鸡，對應(yīng)到表的切分就是表記錄數(shù)相同但包含不同的列胯努。例如，示意圖中的垂直切分逢防，會(huì)把表切分為兩個(gè)表叶沛，一個(gè)表包含 ID、name忘朝、age灰署、sex 列，另外一個(gè)表包含 ID、nickname溉箕、description 列晦墙。

從左往右切就是水平切分，因?yàn)榈兜倪\(yùn)行軌跡與蛋糕是平行的肴茄，這樣可以把蛋糕切成面積相等（高度可以相等也可以不相等）的兩部分晌畅，對應(yīng)到表的切分就是表的列相同但包含不同的行數(shù)據(jù)。例如寡痰，示意圖中的水平切分抗楔，會(huì)把表分為兩個(gè)表，兩個(gè)表都包含 ID拦坠、name连躏、age、sex贞滨、nickname入热、description 列，但是一個(gè)表包含的是 ID 從 1 到 999999 的行數(shù)據(jù)疲迂，另一個(gè)表包含的是 ID 從 1000000 到 9999999 的行數(shù)據(jù)才顿。

上面這個(gè)示例比較簡單，只考慮了一次切分的情況尤蒿，實(shí)際架構(gòu)設(shè)計(jì)過程中并不局限切分的次數(shù)郑气，可以切兩次，也可以切很多次腰池，就像切蛋糕一樣尾组，可以切很多刀。

單表進(jìn)行切分后示弓，是否要將切分后的多個(gè)表分散在不同的數(shù)據(jù)庫服務(wù)器中讳侨，可以根據(jù)實(shí)際的切分效果來確定，并不強(qiáng)制要求單表切分為多表后一定要分散到不同數(shù)據(jù)庫中奏属。原因在于單表切分為多表后跨跨，新的表即使在同一個(gè)數(shù)據(jù)庫服務(wù)器中，也可能帶來可觀的性能提升囱皿，如果性能能夠滿足業(yè)務(wù)要求勇婴，是可以不拆分到多臺(tái)數(shù)據(jù)庫服務(wù)器的，畢竟我們在上面業(yè)務(wù)分庫的內(nèi)容看到業(yè)務(wù)分庫也會(huì)引入很多復(fù)雜性的問題嘱腥；如果單表拆分為多表后耕渴，單臺(tái)服務(wù)器依然無法滿足性能要求，那就不得不再次進(jìn)行業(yè)務(wù)分庫的設(shè)計(jì)了齿兔。

分表能夠有效地分散存儲(chǔ)壓力和帶來性能提升橱脸，但和分庫一樣础米，也會(huì)引入各種復(fù)雜性。

1. 垂直分表

垂直分表適合將表中某些不常用且占了大量空間的列拆分出去添诉。例如屁桑，前面示意圖中的 nickname 和 description 字段，假設(shè)我們是一個(gè)婚戀網(wǎng)站吻商，用戶在篩選其他用戶的時(shí)候掏颊，主要是用 age 和 sex 兩個(gè)字段進(jìn)行查詢，而 nickname 和 description 兩個(gè)字段主要用于展示艾帐，一般不會(huì)在業(yè)務(wù)查詢中用到。description 本身又比較長盆偿，因此我們可以將這兩個(gè)字段獨(dú)立到另外一張表中柒爸，這樣在查詢 age 和 sex 時(shí)，就能帶來一定的性能提升事扭。

垂直分表引入的復(fù)雜性主要體現(xiàn)在表操作的數(shù)量要增加捎稚。例如，原來只要一次查詢就可以獲取 name求橄、age今野、sex、nickname罐农、description条霜，現(xiàn)在需要兩次查詢，一次查詢獲取 name涵亏、age宰睡、sex，另外一次查詢獲取 nickname气筋、description拆内。

不過相比接下來要講的水平分表，這個(gè)復(fù)雜性就是小巫見大巫了宠默。

2. 水平分表

水平分表適合表行數(shù)特別大的表麸恍，有的公司要求單表行數(shù)超過 5000 萬就必須進(jìn)行分表，這個(gè)數(shù)字可以作為參考搀矫，但并不是絕對標(biāo)準(zhǔn)抹沪，關(guān)鍵還是要看表的訪問性能。對于一些比較復(fù)雜的表艾君，可能超過 1000 萬就要分表了采够；而對于一些簡單的表，即使存儲(chǔ)數(shù)據(jù)超過 1 億行冰垄，也可以不分表蹬癌。但不管怎樣权她，當(dāng)看到表的數(shù)據(jù)量達(dá)到千萬級別時(shí)，作為架構(gòu)師就要警覺起來逝薪，因?yàn)檫@很可能是架構(gòu)的性能瓶頸或者隱患隅要。

水平分表相比垂直分表，會(huì)引入更多的復(fù)雜性董济，主要表現(xiàn)在下面幾個(gè)方面：

（1）路由

水平分表后步清，某條數(shù)據(jù)具體屬于哪個(gè)切分后的子表，需要增加路由算法進(jìn)行計(jì)算虏肾，這個(gè)算法會(huì)引入一定的復(fù)雜性廓啊。

常見的路由算法有：

1）范圍路由：選取有序的數(shù)據(jù)列（例如，整形封豪、時(shí)間戳等）作為路由的條件谴轮，不同分段分散到不同的數(shù)據(jù)庫表中。以最常見的用戶 ID 為例吹埠，路由算法可以按照 1000000 的范圍大小進(jìn)行分段第步，1 ~ 999999 放到數(shù)據(jù)庫 1 的表中，1000000 ~ 1999999 放到數(shù)據(jù)庫 2 的表中缘琅，以此類推粘都。

范圍路由設(shè)計(jì)的復(fù)雜點(diǎn)主要體現(xiàn)在分段大小的選取上，分段太小會(huì)導(dǎo)致切分后子表數(shù)量過多刷袍，增加維護(hù)復(fù)雜度翩隧；分段太大可能會(huì)導(dǎo)致單表依然存在性能問題，一般建議分段大小在 100 萬至 2000 萬之間做个，具體需要根據(jù)業(yè)務(wù)選取合適的分段大小鸽心。

范圍路由的優(yōu)點(diǎn)是可以隨著數(shù)據(jù)的增加平滑地?cái)U(kuò)充新的表。例如居暖，現(xiàn)在的用戶是 100 萬顽频，如果增加到 1000 萬，只需要增加新的表就可以了太闺，原有的數(shù)據(jù)不需要?jiǎng)?/b>糯景。

范圍路由的一個(gè)比較隱含的缺點(diǎn)是分布不均勻，假如按照 1000 萬來進(jìn)行分表省骂，有可能某個(gè)分段實(shí)際存儲(chǔ)的數(shù)據(jù)量只有 1000 條蟀淮，而另外一個(gè)分段實(shí)際存儲(chǔ)的數(shù)據(jù)量有 900 萬條。

2）Hash 路由：選取某個(gè)列（或者某幾個(gè)列組合也可以）的值進(jìn)行 Hash 運(yùn)算钞澳，然后根據(jù) Hash 結(jié)果分散到不同的數(shù)據(jù)庫表中怠惶。同樣以用戶 ID 為例，假如我們一開始就規(guī)劃了 10 個(gè)數(shù)據(jù)庫表轧粟，路由算法可以簡單地用 user_id % 10 的值來表示數(shù)據(jù)所屬的數(shù)據(jù)庫表編號策治，ID 為 985 的用戶放到編號為 5 的子表中脓魏，ID 為 10086 的用戶放到編號為 6 的字表中。

Hash 路由設(shè)計(jì)的復(fù)雜點(diǎn)主要體現(xiàn)在初始表數(shù)量的選取上通惫，表數(shù)量太多維護(hù)比較麻煩茂翔，表數(shù)量太少又可能導(dǎo)致單表性能存在問題。而用了 Hash 路由后履腋，增加字表數(shù)量是非常麻煩的珊燎，所有數(shù)據(jù)都要重分布。

Hash 路由的優(yōu)缺點(diǎn)和范圍路由基本相反遵湖，Hash 路由的優(yōu)點(diǎn)是表分布比較均勻悔政，缺點(diǎn)是擴(kuò)充新的表很麻煩，所有數(shù)據(jù)都要重分布延旧。

3）配置路由：配置路由就是路由表卓箫，用一張獨(dú)立的表來記錄路由信息。同樣以用戶 ID 為例垄潮，我們新增一張 user_router 表，這個(gè)表包含 user_id 和 table_id 兩列闷盔，根據(jù) user_id 就可以查詢對應(yīng)的 table_id弯洗。

配置路由設(shè)計(jì)簡單，使用起來非常靈活逢勾，尤其是在擴(kuò)充表的時(shí)候牡整，只需要遷移指定的數(shù)據(jù)，然后修改路由表就可以了溺拱。

配置路由的缺點(diǎn)就是必須多查詢一次逃贝，會(huì)影響整體性能；而且路由表本身如果太大（例如迫摔，幾億條數(shù)據(jù)）沐扳，性能同樣可能成為瓶頸，如果我們再次將路由表分庫分表句占，則又面臨一個(gè)死循環(huán)式的路由算法選擇問題沪摄。

（2）join 操作

水平分表后，數(shù)據(jù)分散在多個(gè)表中纱烘，如果需要與其他表進(jìn)行 join 查詢杨拐，需要在業(yè)務(wù)代碼或者數(shù)據(jù)庫中間件中進(jìn)行多次 join 查詢，然后將結(jié)果合并擂啥。

（3）count() 操作

水平分表后哄陶，雖然物理上數(shù)據(jù)分散到多個(gè)表中，但某些業(yè)務(wù)邏輯上還是會(huì)將這些表當(dāng)作一個(gè)表來處理哺壶。例如屋吨，獲取記錄總數(shù)用于分頁或者展示蜒谤，水平分表前用一個(gè) count() 就能完成的操作，在分表后就沒那么簡單了离赫。常見的處理方式有下面兩種：

count() 相加：具體做法是在業(yè)務(wù)代碼或者數(shù)據(jù)庫中間件中對每個(gè)表進(jìn)行 count() 操作芭逝，然后將結(jié)果相加。這種方式實(shí)現(xiàn)簡單渊胸，缺點(diǎn)就是性能比較低旬盯。例如，水平分表后切分為 20 張表翎猛，則要進(jìn)行 20 次 count(*) 操作胖翰，如果串行的話，可能需要幾秒鐘才能得到結(jié)果切厘。

記錄數(shù)表：具體做法是新建一張表萨咳，假如表名為“記錄數(shù)表”，包含 table_name疫稿、row_count 兩個(gè)字段培他，每次插入或者刪除子表數(shù)據(jù)成功后，都更新“記錄數(shù)表”遗座。

這種方式獲取表記錄數(shù)的性能要大大優(yōu)于 count() 相加的方式舀凛，因?yàn)橹恍枰淮魏唵尾樵兙涂梢垣@取數(shù)據(jù)。缺點(diǎn)是復(fù)雜度增加不少途蒋，對子表的操作要同步操作“記錄數(shù)表”猛遍，如果有一個(gè)業(yè)務(wù)邏輯遺漏了，數(shù)據(jù)就會(huì)不一致号坡；且針對“記錄數(shù)表”的操作和針對子表的操作無法放在同一事務(wù)中進(jìn)行處理懊烤，異常的情況下會(huì)出現(xiàn)操作子表成功了而操作記錄數(shù)表失敗，同樣會(huì)導(dǎo)致數(shù)據(jù)不一致宽堆。

此外腌紧，記錄數(shù)表的方式也增加了數(shù)據(jù)庫的寫壓力，因?yàn)槊看吾槍ψ颖淼?insert 和 delete 操作都要 update 記錄數(shù)表日麸，所以對于一些不要求記錄數(shù)實(shí)時(shí)保持精確的業(yè)務(wù)寄啼，也可以通過后臺(tái)定時(shí)更新記錄數(shù)表。定時(shí)更新實(shí)際上就是“count() 相加”和“記錄數(shù)表”的結(jié)合代箭，即定時(shí)通過 count() 相加計(jì)算表的記錄數(shù)墩划，然后更新記錄數(shù)表中的數(shù)據(jù)。

（4）order by 操作

水平分表后嗡综，數(shù)據(jù)分散到多個(gè)子表中乙帮，排序操作無法在數(shù)據(jù)庫中完成，只能由業(yè)務(wù)代碼或者數(shù)據(jù)庫中間件分別查詢每個(gè)子表中的數(shù)據(jù)极景，然后匯總進(jìn)行排序察净。

實(shí)現(xiàn)方法

和數(shù)據(jù)庫讀寫分離類似驾茴，分庫分表具體的實(shí)現(xiàn)方式也是“程序代碼封裝”和“中間件封裝”，但實(shí)現(xiàn)會(huì)更復(fù)雜氢卡。讀寫分離實(shí)現(xiàn)時(shí)只要識(shí)別 SQL 操作是讀操作還是寫操作锈至，通過簡單的判斷 SELECT、UPDATE译秦、INSERT峡捡、DELETE 幾個(gè)關(guān)鍵字就可以做到，而分庫分表的實(shí)現(xiàn)除了要判斷操作類型外筑悴，還要判斷 SQL 中具體需要操作的表们拙、操作函數(shù)（例如 count 函數(shù))、order by阁吝、group by 操作等砚婆，然后再根據(jù)不同的操作進(jìn)行不同的處理。例如 order by 操作突勇，需要先從多個(gè)庫查詢到各個(gè)庫的數(shù)據(jù)装盯，然后再重新 order by 才能得到最終的結(jié)果。

小結(jié)

什么時(shí)候引入分庫分表是合適的甲馋？是數(shù)據(jù)庫性能不夠的時(shí)候就開始分庫分表么验夯？

評論1

應(yīng)該是這些操作依次嘗試

1.做硬件優(yōu)化，例如從機(jī)械硬盤改成使用固態(tài)硬盤摔刁，當(dāng)然固態(tài)硬盤不適合服務(wù)器使用，只是舉個(gè)例子

2.先做數(shù)據(jù)庫服務(wù)器的調(diào)優(yōu)操作海蔽，例如增加索引共屈，oracle有很多的參數(shù)調(diào)整;

3.引入緩存技術(shù)，例如Redis党窜，減少數(shù)據(jù)庫壓力

4.程序與數(shù)據(jù)庫表優(yōu)化拗引，重構(gòu)，例如根據(jù)業(yè)務(wù)邏輯對程序邏輯做優(yōu)化幌衣，減少不必要的查詢;

5.在這些操作都不能大幅度優(yōu)化性能的情況下矾削，不能滿足將來的發(fā)展，再考慮分庫分表豁护，也要有預(yù)估性

評論2哼凯？

分流了存儲(chǔ)壓力與讀寫壓力，當(dāng)線上已經(jīng)進(jìn)行了分庫分表的系統(tǒng)楚里，需要進(jìn)一步水平擴(kuò)容時(shí)断部，有什么好的設(shè)計(jì)方案？一開始的分表方案就是按照id范圍來設(shè)計(jì)的班缎，要么就需要數(shù)據(jù)遷移

評論3

如果表中有內(nèi)容較長的字段蝴光，查詢的時(shí)候不查出來（不使用select *）她渴，也會(huì)有性能問題？關(guān)系數(shù)據(jù)庫是行存儲(chǔ)蔑祟，即使不用那一列趁耗，也會(huì)從存儲(chǔ)讀取到內(nèi)存

評論4？

其實(shí)hash還有一個(gè)問題疆虚，就是當(dāng)新增一張表時(shí)苛败，怎么處理，比如說我原來是10張表装蓬，現(xiàn)在要增加到11張表著拭，可以用一致性hash解決，但也會(huì)有數(shù)據(jù)遷移問題

評論5牍帚？

針對消費(fèi)者端訂單表按用戶ID哈希規(guī)則分表儡遮，這樣所有對用戶訂單的查詢條件全都帶上用戶ID，達(dá)到了數(shù)據(jù)分片的效果暗赶。

但這時(shí)商家端需要對訂單做管理鄙币，就很尷尬了。于是我想到蹂随，可以將訂單數(shù)據(jù)做同步到另一個(gè)數(shù)據(jù)源十嘿，表結(jié)構(gòu)一致只是按照商家ID進(jìn)行哈希規(guī)則分表，所有商家端查詢走此數(shù)據(jù)源岳锁，條件全部帶上商家ID绩衷，也可以做到數(shù)據(jù)分片的效果。

接下來問題又來了激率，系統(tǒng)還有一個(gè)平臺(tái)的視角咳燕，這時(shí)貌似不好沿著這個(gè)思路繼續(xù)了，懇請老師提點(diǎn)提點(diǎn)乒躺。

淘寶的單元化改造就面臨你說的問題招盲，最后他們選擇了買家緯度拆分，賣家緯度不拆分嘉冒，詳細(xì)可以搜網(wǎng)上的公開資料曹货。

評論6？

如何實(shí)現(xiàn)對業(yè)務(wù)透明的分表讳推，同時(shí)也能支持?jǐn)?shù)據(jù)庫join顶籽，group by等操作。只有中間件和中間層能做到银觅，例如TDDL