在講數(shù)據(jù)庫(kù)水平拆分時(shí)候，我列出了水平拆分?jǐn)?shù)據(jù)庫(kù)需要解決的兩個(gè)難題，它們分別是主鍵的設(shè)計(jì)問(wèn)題和單表查詢的問(wèn)題，主鍵問(wèn)題前文已經(jīng)做了比較詳細(xì)的講述了，但是第二個(gè)問(wèn)題我沒有講述，今天我將會(huì)講講如何解決數(shù)據(jù)表被垂直拆分后的單表查詢問(wèn)題。

?

　　要解決數(shù)據(jù)表被水平拆分后的單表查詢問(wèn)題，我們首先要回到問(wèn)題的源頭，我們?yōu)槭裁葱枰獙?shù)據(jù)庫(kù)的表進(jìn)行水平拆分。下面我們來(lái)推導(dǎo)下我們最終下定決心做水平拆分表的演進(jìn)過(guò)程，具體如下：

?

　　第一個(gè)演進(jìn)過(guò)程 ：進(jìn)行了讀寫分離的表在數(shù)據(jù)增長(zhǎng)后需要進(jìn)行水平拆分嗎？回答這個(gè)疑問(wèn)我們首先要想想進(jìn)行讀寫分離操作的表真的是因?yàn)閿?shù)據(jù)量大嗎？答案其實(shí)是否定的。 最基本的讀寫分離的目的是為了解決數(shù)據(jù)庫(kù)的某張表讀寫比率嚴(yán)重失衡的問(wèn)題 ， 舉個(gè)例子，有一張表每天會(huì)增加1萬(wàn)條數(shù)據(jù)，也就是說(shuō)我們的系統(tǒng)每天會(huì)向這張表做1萬(wàn)次寫的操作，當(dāng)然也有可能我們還會(huì)更新或者刪除這張表的某些已有的記 錄，這些操作我們把它歸并到寫操作，那么這張表一天我們隨意定義個(gè)估值吧2萬(wàn)5千次寫操作，其實(shí)這種表的數(shù)據(jù)量并不大，一年下來(lái)也就新增的幾百萬(wàn)條數(shù)據(jù)， 一個(gè)大型的商業(yè)級(jí)別的關(guān)系數(shù)據(jù)庫(kù)，當(dāng)我們?yōu)楸斫⒑盟饕头謪^(qū)后，查詢幾百萬(wàn)條數(shù)據(jù)它的效率并不低，這么說(shuō)來(lái)查詢的效率問(wèn)題還不一定是讀寫分離的源頭。其 實(shí)啊，這張表除了寫操作每天還承受的讀操作可能會(huì)是10萬(wàn)，20萬(wàn)甚至更高，這個(gè)時(shí)候問(wèn)題來(lái)了，像oracle和mysql這樣鼎鼎大名的關(guān)系數(shù)據(jù)庫(kù)默認(rèn) 的最大連接數(shù)是100，一般上了生產(chǎn)環(huán)境我們可能會(huì)設(shè)置為150或者200，這些連接數(shù)已經(jīng)到了這些關(guān)系數(shù)據(jù)庫(kù)的最大極限了，如果再加以提升，數(shù)據(jù)庫(kù)性能 會(huì)嚴(yán)重下降，最終很有可能導(dǎo)致數(shù)據(jù)庫(kù)由于壓力過(guò)大而變成了一個(gè)巨鎖，最終導(dǎo)致系統(tǒng)發(fā)生503的錯(cuò)誤，如是我們就會(huì)想到采用讀寫分離方案，將數(shù)據(jù)庫(kù)的讀操作 遷移到專門的讀庫(kù)里，如果系統(tǒng)的負(fù)載指標(biāo)和我列舉的例子相仿，那么遷移的讀庫(kù)甚至不用做什么垂直拆分就能滿足實(shí)際的業(yè)務(wù)需求，因?yàn)槲覀兊哪康闹皇菫榱藴p輕 數(shù)據(jù)庫(kù)的連接壓力。

?

　　第二個(gè)演進(jìn)過(guò)程 ： 隨著公司業(yè)務(wù)的不斷增長(zhǎng)，系統(tǒng)的運(yùn)行的壓力也越來(lái)越大了，我們已經(jīng)了解了系統(tǒng)的第一個(gè)瓶頸是從存儲(chǔ)開始了，如是我們開始談?wù)摲桨溉绾谓鉀Q存儲(chǔ)的問(wèn)題，這時(shí) 我們發(fā)現(xiàn)我們已經(jīng)做了讀寫分離，也使用了緩存，甚至連搜索技術(shù)也用上了，那么下個(gè)階段就是垂直拆分了，垂直拆分很簡(jiǎn)單就是把表從數(shù)據(jù)庫(kù)里拆出來(lái)，單獨(dú)建庫(kù) 建表，但是這種直截了當(dāng)?shù)姆桨赶胂刖湍芨械竭@樣的做法似乎沒有打中系統(tǒng)的痛點(diǎn)，那么系統(tǒng)的痛點(diǎn)到底是什么呢？根據(jù)數(shù)據(jù)庫(kù)本身的特性，我們會(huì)發(fā)現(xiàn)痛點(diǎn)主要是 三個(gè)方面組成：

?

第一個(gè)方面：數(shù)據(jù)庫(kù)的連接數(shù)的限制 。 原庫(kù)的某些表可能承擔(dān)數(shù)據(jù)庫(kù)80%的連接，極端下甚至可以超過(guò)90%的連接，而且這些表的業(yè)務(wù)操作十分的頻繁，當(dāng)其他小眾業(yè)務(wù)的表需要進(jìn)行操作時(shí)候，搞不 好因?yàn)檫B接數(shù)被全部占用而不得不排隊(duì)等待空閑連接的出現(xiàn)，那么這個(gè)時(shí)候我們就會(huì)考慮把這張表做垂直拆分，這樣就減輕了原數(shù)據(jù)庫(kù)連接的壓力，使得數(shù)據(jù)庫(kù)連接 負(fù)載變得比較均衡。

?

第二個(gè)方面是數(shù)據(jù)庫(kù)的讀操作，第三個(gè)方面是數(shù)據(jù)庫(kù)的寫操作 ， 雖然把讀和寫分成兩個(gè)方面，但是這兩個(gè)方面在我們做垂直拆分時(shí)候要結(jié)合起來(lái)考慮。首先我們要分析下數(shù)據(jù)庫(kù)的寫操作，單獨(dú)的寫操作效率都是很高的，不管我們 的寫是單條記錄的寫操作，還是批量的寫操作，這些寫操作的數(shù)據(jù)量就是我們要去寫的數(shù)據(jù)的大小，因此控制寫的數(shù)據(jù)量的大小是一件很容易很天然的操作，所以這 些操作不會(huì)造成數(shù)據(jù)庫(kù)太大負(fù)擔(dān)，詳細(xì)點(diǎn)的話，對(duì)于數(shù)據(jù)庫(kù)而言，新增操作無(wú)非是在原來(lái)數(shù)據(jù)后面追加些記錄，而修改操作或者刪除操作一般都是通過(guò)建立了高效索 引的字段來(lái)定位數(shù)據(jù)后再進(jìn)行的操作，因此它的性能也是非常高的。而讀操作看起來(lái)比寫操作簡(jiǎn)單（例如：讀操作不存在像事務(wù)這些烏七八糟因素的干擾），但是當(dāng) 讀操作面對(duì)海量數(shù)據(jù)時(shí)候就嚴(yán)重挑戰(zhàn)著數(shù)據(jù)庫(kù)和硬盤的極限能力，因此讀操作很容易產(chǎn)生瓶頸問(wèn)題，而且這個(gè)瓶頸不管問(wèn)題表是否讀寫失衡都會(huì)面臨的。前文里我詳 細(xì)列舉了一個(gè)交易表設(shè)計(jì)的案例，其中我們可以看到數(shù)據(jù)庫(kù)垂直拆分在實(shí)際應(yīng)用里的運(yùn)用，在例子里我們首先根據(jù)業(yè)務(wù)特點(diǎn)將交易表分成了實(shí)時(shí)交易表和歷史交易 表，這個(gè)做法其實(shí)就是將原交易表的讀和寫進(jìn)行分離，但是這種分離和純粹的讀寫分離相比會(huì)更加有深意，這個(gè)深意就是拆分實(shí)時(shí)和歷史交易表也就是在分拆原表的 讀寫操作的關(guān)聯(lián)性，換句話說(shuō)，如果我們不這么做的話，那么交易表的每次寫和每次讀幾乎等價(jià)，這樣我們沒法單獨(dú)解決讀的性能問(wèn)題，分出了歷史交易表后我們?cè)?對(duì)歷史交易表來(lái)做讀的優(yōu)化，那么這也不會(huì)影響到寫操作，這樣把問(wèn)題的復(fù)雜度給降低了。在案例里我們對(duì)歷史交易表進(jìn)行了業(yè)務(wù)級(jí)別的水平拆分，但是這個(gè)拆分是 以如何提升讀的效率進(jìn)行的，因此前文講到的水平拆分里主鍵設(shè)計(jì)方案基本上派不上用場(chǎng)，因?yàn)檫@兩種水平拆分的出發(fā)點(diǎn)是不同的，那么使用的手段和達(dá)到效果也將 不一樣。

?

　　由上所述，我們可以把數(shù)據(jù)庫(kù)的水平拆分重新定義下，我在這幾篇文章里一直講述的水平拆分本質(zhì)是從數(shù)據(jù)庫(kù)技術(shù)來(lái)定義的，我把它們稱為 狹義的水平拆分 ，與狹義相對(duì)的就是 廣義的水平拆分 ，例如上文例子里把交易表根據(jù)業(yè)務(wù)特性分為實(shí)時(shí)交易表和歷史交易表，這種行為也是一種水平拆分，但是這個(gè)拆分不會(huì)遵守我前面講到主鍵設(shè)計(jì)方案，但是它的確達(dá)到水平拆分的目的，所以這樣的水平拆分就屬于廣義的水平拆分了。

?

　　第三個(gè)演進(jìn)過(guò)程 ：到了三個(gè)演進(jìn)過(guò)程我們就會(huì)考慮到真正的水平拆分了，也就是上面提到的狹義的水平拆分了， 狹義的水平拆分執(zhí)行的理由有兩個(gè)，一個(gè)那就是數(shù)據(jù)量太大了，另一個(gè)是數(shù)據(jù)表的讀寫的關(guān)聯(lián)性很難進(jìn)行拆分了 ， 這點(diǎn)和垂直拆分有所不同，做垂直拆分的考慮不一定是因?yàn)閿?shù)據(jù)量過(guò)大，例如某種表數(shù)據(jù)量不大，但是負(fù)載過(guò)重，很容易讓數(shù)據(jù)庫(kù)達(dá)到連接的極限值，我們也會(huì)采取 垂直拆分手段來(lái)解決問(wèn)題，此外，我們想減輕寫操作和讀操作的關(guān)聯(lián)性，從而能單獨(dú)對(duì)有瓶頸的寫操作或讀操作做優(yōu)化設(shè)計(jì)，那么我們也會(huì)考慮到垂直拆分，當(dāng)然數(shù) 據(jù)量實(shí)在是太大的表我們想優(yōu)化，首先也會(huì)考慮到垂直拆分，因?yàn)榇怪辈鸱质轻槍?duì)海量數(shù)據(jù)優(yōu)化的起始手段，但是垂直拆分可不一定能解決海量數(shù)據(jù)的問(wèn)題。

?

　　狹義水平 拆分的使用的前提是因?yàn)閿?shù)據(jù)量太大，到底多大了，我們舉個(gè)例子來(lái)說(shuō)明下，假如某個(gè)電商平臺(tái)一天的交易筆數(shù)有2億筆，我們用來(lái)存儲(chǔ)數(shù)據(jù)的關(guān)系數(shù)據(jù)庫(kù)單表記錄 到了5千萬(wàn)條后，查詢性能就會(huì)嚴(yán)重下降，那么如果我們把這兩億條數(shù)據(jù)全部存進(jìn)這個(gè)數(shù)據(jù)庫(kù)，那么隨著數(shù)據(jù)的累積，實(shí)時(shí)交易查詢基本已經(jīng)沒法正常完成了，這個(gè) 時(shí)候我們就得考慮把實(shí)時(shí)交易表進(jìn)行狹義的水平拆分，狹義的水平拆分首先碰到的難點(diǎn)就是主鍵設(shè)計(jì)的問(wèn)題，主鍵設(shè)計(jì)問(wèn)題也就說(shuō)明狹義水平拆分其實(shí)解決的是海量 數(shù)據(jù)寫的問(wèn)題，如果這張表讀操作很少，或者基本沒有，這個(gè)水平拆分是很好設(shè)計(jì)的，但是一張表只寫不讀，對(duì)于作為業(yè)務(wù)系統(tǒng)的后臺(tái)數(shù)據(jù)庫(kù)那基本是非常罕見 的，。

?

　　前文講到 的主鍵設(shè)計(jì)方案其實(shí)基本沒有什么業(yè)務(wù)上的意義，它解決的主要問(wèn)題是讓寫入的數(shù)據(jù)分布均勻，從而能合理使用存儲(chǔ)資源，但是這個(gè)合理分布式存儲(chǔ)資源卻會(huì)給查詢 操作帶來(lái)極大的問(wèn)題，甚至有時(shí)可以說(shuō)狹義水平拆分后數(shù)據(jù)查詢變得困難就是由這種看起來(lái)合理的主鍵設(shè)計(jì)方案所致。

?

　　我們還是 以實(shí)時(shí)交易表的實(shí)例來(lái)說(shuō)明問(wèn)題，一個(gè)電商平臺(tái)下會(huì)接入很多不同的商戶，但是不同的商戶每天產(chǎn)生的交易量是不同，也就是說(shuō)商戶的維度會(huì)讓我們使交易數(shù)據(jù)變得 嚴(yán)重的不均衡，可能電商平臺(tái)下不到5%的商戶完成了全天交易量的80%，而其他95%的商戶僅僅完成20%的交易量，但是作為業(yè)務(wù)系統(tǒng)的數(shù)據(jù)表，進(jìn)行讀操 作首先被限制和約束的條件就是商戶號(hào)，如果要為我們?cè)O(shè)計(jì)的實(shí)時(shí)交易表進(jìn)行狹義的水平拆分，做拆分前我們要明確這個(gè)拆分是由交易量大的少量商戶所致，而不是 全部的商戶所致的。如果按照均勻分布主鍵的設(shè)計(jì)方案，不加商戶區(qū)分的分布數(shù)據(jù)，那么就會(huì)發(fā)生產(chǎn)生少量交易數(shù)據(jù)的商戶的查詢行為也要承受交易量大的商戶數(shù)據(jù) 的影響，而能產(chǎn)生大量交易數(shù)據(jù)的商戶也沒有因?yàn)樽约旱呢暙I(xiàn)度而得到應(yīng)有的高級(jí)服務(wù)，碰到這個(gè)問(wèn)題其實(shí)非常好解決，就是在做狹義水平拆分前，我們先做一次廣 義的水平拆分，把交易量大的商戶交易和交易量小的商戶交易拆分出來(lái)，交易量小的商戶用一張表記錄，這樣交易量小的商戶也會(huì)很happy的查詢出需要的數(shù) 據(jù)，心里也是美滋滋的。接下來(lái)我們就要對(duì)交易量大的商戶的交易表開始做狹義的水平拆分了，為這些重點(diǎn)商戶做專門的定制化服務(wù)。

?

　　做狹義水 平拆分前，我們有個(gè)問(wèn)題需要過(guò)一下，在狹義水平拆分前我們需要先做一下廣義的水平拆分嗎？這個(gè)我這里不好說(shuō)，具體要看實(shí)際的業(yè)務(wù)場(chǎng)景，但是針對(duì)我列舉的實(shí) 時(shí)交易的例子而言，我覺得沒那個(gè)必要，因此拆分出的重點(diǎn)商戶交易量本來(lái)就很大，每個(gè)都在挑戰(zhàn)數(shù)據(jù)庫(kù)讀能力的極限，更重要的是實(shí)時(shí)交易數(shù)據(jù)的時(shí)間粒度已經(jīng)很 小了，再去做廣義水平拆分難度很大，而且很難做好，所以這個(gè)時(shí)候我們還是直接使用狹義的水平拆分。拆分完畢后我們就要解決查詢問(wèn)題了。

?

　　做實(shí)時(shí)查詢的標(biāo)準(zhǔn)做法就是分頁(yè)查詢了，在講述如何解決分頁(yè)查詢前，我們看看我們?cè)谔詫毨锼阉鳌疽路窟@個(gè)條件的分頁(yè)情況，如下圖所示：

?

?

　　我們看到 一共才100頁(yè)，淘寶上衣服的商品最多了，居然搜索出來(lái)的總頁(yè)數(shù)只有100頁(yè)，這是不是在挑戰(zhàn)我們的常識(shí)啊，淘寶的這個(gè)做法也給我們?cè)趯?shí)現(xiàn)水平拆分后如何 做分頁(yè)查詢一種啟迪。要說(shuō)明這個(gè)啟迪前我們首先要看看傳統(tǒng)的分頁(yè)是如何做的，傳統(tǒng)分頁(yè)的做法是首先使用select count(1) form table這樣的語(yǔ)句查詢出需要查詢數(shù)據(jù)的總數(shù)，然后再根據(jù)每頁(yè)顯示的記錄條數(shù)，查詢出需要顯示的記錄，然后頁(yè)面根據(jù)記錄總數(shù)，每頁(yè)的條數(shù)，和查詢的結(jié)果 來(lái)完成分頁(yè)查詢。回到我們的交易表實(shí)例里，有一個(gè)重要商戶在做實(shí)時(shí)交易查詢，可是這個(gè)時(shí)候該商戶已經(jīng)產(chǎn)生了1千萬(wàn)筆交易了，假如每頁(yè)顯示10條，記錄那么 我們就要分成100萬(wàn)頁(yè)，這要是真顯示在頁(yè)面上，絕對(duì)能讓我們這些開發(fā)人員像哥倫布發(fā)現(xiàn)新大陸那樣驚奇，反正我見過(guò)的最多分頁(yè)也就是200多頁(yè)，還是在百 度搜索發(fā)現(xiàn)的。其實(shí)當(dāng)數(shù)據(jù)庫(kù)一張表的數(shù)據(jù)量非常大的時(shí)候，select的count查詢效率就非常低下，這個(gè)查詢有時(shí)也會(huì)近似個(gè)全表檢索，所以count 查詢還沒結(jié)束我們就會(huì)失去等待結(jié)果的耐心了，更不要是說(shuō)等把數(shù)據(jù)查詢出來(lái)了，所以這個(gè)時(shí)候我們可以學(xué)習(xí)下淘寶的做法，當(dāng)商戶第一次查詢我們準(zhǔn)許他查詢有限 的數(shù)據(jù)。我自己所做的一個(gè)項(xiàng)目的做法就是這樣的，當(dāng)某個(gè)商戶的交易量實(shí)在是很大時(shí)候我們其實(shí)不會(huì)計(jì)算數(shù)據(jù)的總筆數(shù)，而是一次性查詢出1000條數(shù)據(jù)，這 1000條數(shù)據(jù)查詢出來(lái)后存入到緩存里，頁(yè)面則只分100頁(yè)，當(dāng)用戶一定要查詢100頁(yè)后的數(shù)據(jù)，我們?cè)偃プ芳硬樵儯贿^(guò)實(shí)踐下來(lái)，商戶基本很少會(huì)查詢 100頁(yè)后的數(shù)據(jù)，常常看了5，6頁(yè)就會(huì)停止查詢了。不過(guò)商戶也時(shí)常會(huì)有查詢?nèi)繑?shù)據(jù)的需求，但是商戶有這種需求的目的也不是想在分頁(yè)查詢里看的，一般都 是為了比對(duì)數(shù)據(jù)使用的，這個(gè)時(shí)候我們一般是提供一個(gè)發(fā)起下載查詢?nèi)拷灰椎墓δ茼?yè)面，商戶根據(jù)自己的條件先發(fā)起這樣的需求，然后我們系統(tǒng)會(huì)在后臺(tái)單獨(dú)起個(gè) 線程查詢出全部數(shù)據(jù)，生成一個(gè)固定格式的文件，最后通過(guò)一些有效手段通知商戶數(shù)據(jù)生成好了，讓商戶下載文件即可。

?

　　對(duì)于進(jìn)行 了狹義水平拆分的表做分頁(yè)查詢我們通常都不會(huì)是全表查詢，而是抽取全局的數(shù)據(jù)的一部分結(jié)果呈現(xiàn)給用戶，這個(gè)做法其實(shí)和很多市場(chǎng)調(diào)查的方式類似，市場(chǎng)調(diào)查我 們通常是找一些樣本采集相關(guān)數(shù)據(jù)，通過(guò)分析這些樣本數(shù)據(jù)推導(dǎo)出全局的一個(gè)發(fā)展趨勢(shì)，那么這些樣本選擇的合理性就和最終的結(jié)論有很大關(guān)系，回到狹義水平拆分 的表做分頁(yè)查詢，我們?yōu)榱思皶r(shí)滿足用戶需求，我們只是取出了全部數(shù)據(jù)中的一部分，但是這一部分?jǐn)?shù)據(jù)是否滿足用戶的需求，這個(gè)問(wèn)題是很有學(xué)問(wèn)的，如果是交易 表，我們往往是按時(shí)間先后順序查詢部分?jǐn)?shù)據(jù)，所以這里其實(shí)使用到了一個(gè)時(shí)間的維度，其他業(yè)務(wù)的表可能這個(gè)維度會(huì)不一樣，但肯定是有個(gè)維度約束我們到底返回 那些部分的數(shù)據(jù)。這個(gè)維度可以用一個(gè)專有的名詞指代那就是排序，具體點(diǎn)就是要那個(gè)字段進(jìn)行升序還是降序查詢，看到這里肯定有人會(huì)有異議，那就是這種抽樣式 的查詢，肯定會(huì)導(dǎo)致查詢的命中率的問(wèn)題，即查出來(lái)的數(shù)據(jù)不一定全部都是我們要的，其實(shí)要想讓數(shù)據(jù)排序正確，最好就是做全量排序，但是一到全量排序那就是全 表查詢，做海量數(shù)據(jù)的全表排序查詢對(duì)于分頁(yè)這種場(chǎng)景是無(wú)法完成的。回到淘寶的例子，我們相信淘寶肯定沒有返回全部數(shù)據(jù)，而是抽取了部分?jǐn)?shù)據(jù)分頁(yè)，也就是淘 寶查詢時(shí)候加入了維度，每個(gè)淘寶的店家都希望自己的商戶放在搜索的前列，那么淘寶就可以讓商家掏錢，付了錢以后淘寶改變下商家在這個(gè)維度里的權(quán)重，那么商 家的商品就可以排名靠前了。

?

　　狹義水平 拆分的本身對(duì)排序也有很大的影響，水平拆分后我們一個(gè)分頁(yè)查詢可能要從不同數(shù)據(jù)庫(kù)不同的物理表里去取數(shù)據(jù)，單表下我們可以先通過(guò)數(shù)據(jù)庫(kù)的排序算法得到一定 的數(shù)據(jù)，但是局部的排序到了全局可能就不正確了，這個(gè)又該怎么辦了？其實(shí)由上面內(nèi)容我們可以知道要滿足對(duì)海量數(shù)據(jù)的所有查詢限制是非常難的，時(shí)常是根本就 無(wú)法滿足，我們只能做到盡量多滿足些查詢限制，也就是海量查詢只能做到盡量接近查詢限制的條件，而很難完全滿足，這個(gè)時(shí)候我前面提到的主鍵分布方案就能起 到作用了，我們?cè)谠O(shè)計(jì)狹義水平拆分表主鍵分布時(shí)候是盡量保持?jǐn)?shù)據(jù)分布均衡，那么如果我們查詢要從多張不同物理表里取的時(shí)候，例如我們要查1000條數(shù)據(jù)， 而狹義水平拆分出了兩個(gè)物理數(shù)據(jù)庫(kù)，那么我們就可以每個(gè)數(shù)據(jù)庫(kù)查詢500條，然后在服務(wù)層歸并成1000條數(shù)據(jù)，在服務(wù)層排序，這種場(chǎng)景下如果我們的主鍵 設(shè)計(jì)時(shí)候還包含點(diǎn)業(yè)務(wù)意義，那么這個(gè)排序的精確度就會(huì)得到很大提升。假如用戶對(duì)排序不敏感，那就更好做了，分頁(yè)時(shí)候如果每頁(yè)規(guī)定顯示10條，我們可以把 10條數(shù)據(jù)平均分配給兩個(gè)數(shù)據(jù)庫(kù)，也就是顯示10條A庫(kù)的數(shù)據(jù)，再顯示5條B庫(kù)的數(shù)據(jù)。

?

　　看到這里 有些細(xì)心的朋友可能還會(huì)有疑問(wèn)，那就是居然排序是分頁(yè)查詢的痛點(diǎn)，那么我們可以不用數(shù)據(jù)庫(kù)查詢，而使用搜索技術(shù)啊，NoSql數(shù)據(jù)庫(kù)啊，的確這些技術(shù)可以 更好的解決分頁(yè)問(wèn)題，但是關(guān)系數(shù)據(jù)庫(kù)過(guò)渡到搜索引擎和NoSql數(shù)據(jù)庫(kù)首先需要我們轉(zhuǎn)化數(shù)據(jù)，而狹義的水平拆分的數(shù)據(jù)表本身數(shù)據(jù)量很大，這個(gè)轉(zhuǎn)化過(guò)程我們 是沒法快速完成的，如果我們對(duì)延時(shí)容忍度那么高，其實(shí)我們就沒必要去做數(shù)據(jù)庫(kù)的狹義水平拆分了。這個(gè)問(wèn)題反過(guò)來(lái)說(shuō)明了使用狹義拆分?jǐn)?shù)據(jù)表的業(yè)務(wù)場(chǎng)景，那就 是： 針對(duì)數(shù)據(jù)量很大的表同時(shí)該表的讀寫的關(guān)聯(lián)性是沒法有效拆分的 。

?

　　最后我要 講的是，如果系統(tǒng)到了狹義水平拆分都沒法解決時(shí)候，我們就要拋棄傳統(tǒng)的關(guān)系數(shù)據(jù)方案了，將該業(yè)務(wù)全部使用NoSql數(shù)據(jù)庫(kù)解決或者像很多大型互聯(lián)網(wǎng)公司那 樣，改寫開源的mysql數(shù)據(jù)庫(kù)。文章寫道這里，我還是想說(shuō)一個(gè)觀點(diǎn)，如果一個(gè)系統(tǒng)有很強(qiáng)烈需求去做狹義的水平拆分，那么這個(gè)公司的某個(gè)業(yè)務(wù)那肯定是非常 的大了，所以啊，這個(gè)方案以公司為單位應(yīng)該有點(diǎn)小眾了。

?

　　好了，今天寫到這里，祝大家晚安，生活愉快。

?

原文： http://www.cnblogs.com/sharpxiajun/p/4271353.html