海量數(shù)據(jù)庫(kù)解決方案？將整體內(nèi)容分為兩部分，在第1部分中以影響數(shù)據(jù)讀取效率的所有要素為類(lèi)別，對(duì)其各自的概念、原理、 特征、應(yīng)用準(zhǔn)則，以及表的結(jié)構(gòu)特征、多樣化的索引類(lèi)型、優(yōu)化器的內(nèi)部作用、優(yōu)化器為各種結(jié)果

海量數(shù)據(jù)庫(kù)解決方案？

將整體內(nèi)容分為兩部分，在第1部分中以影響數(shù)據(jù)讀取效率的所有要素為類(lèi)別，對(duì)其各自的概念、原理、 特征、應(yīng)用準(zhǔn)則，以及表的結(jié)構(gòu)特征、多樣化的索引類(lèi)型、優(yōu)化器的內(nèi)部作用、優(yōu)化器為各種結(jié)果制定的執(zhí)行計(jì)劃予以詳細(xì)說(shuō)明，并以對(duì)優(yōu)化器的正確理解為基礎(chǔ)，提出對(duì)執(zhí)行計(jì)劃和執(zhí)行速度產(chǎn)生最大影響的索引構(gòu)建戰(zhàn)略方案；在第2部分中主要介紹提高數(shù)據(jù)讀取效率的具體戰(zhàn)略方案，在這部分中介紹與數(shù)據(jù)讀取效率相關(guān)的局部范圍掃描的原理和具體應(yīng)用方法，以及對(duì)被認(rèn)為是提高數(shù)據(jù)庫(kù)使用效率基礎(chǔ)的表連接的所有類(lèi)型予以詳細(xì)說(shuō)明。

mysql表數(shù)據(jù)量太大，達(dá)到了1億多條數(shù)據(jù)，除了分庫(kù)分表之外，還有沒(méi)有其他的解決方式？

mysql在常規(guī)配置下，一般只能承受2000萬(wàn)的數(shù)據(jù)量(同時(shí)讀寫(xiě)，且表中有大文本字段，單臺(tái)服務(wù)器)?，F(xiàn)在超過(guò)1億，并不斷增加的情況下，建議如下處理：

1 分表?？梢园磿r(shí)間，或按一定的規(guī)則拆分，做到查詢(xún)某一條數(shù)據(jù)庫(kù)，盡量在一個(gè)子表中即可。這是最有效的方法

2 讀寫(xiě)分離。尤其是寫(xiě)入，放在新表中，定期進(jìn)行同步。如果其中記錄不斷有update，最好將寫(xiě)的數(shù)據(jù)放在 redis中，定期同步

3 表的大文本字段分離出來(lái)，成為獨(dú)立的新表。大文本字段，可以使用NOSQL數(shù)據(jù)庫(kù)

4 優(yōu)化架構(gòu)，或優(yōu)化SQL查詢(xún)，避免聯(lián)表查詢(xún)，盡量不要用count(*)， in，遞歸等消耗性能的語(yǔ)句

5 用內(nèi)存緩存，或在前端讀的時(shí)候，增加緩存數(shù)據(jù)庫(kù)。重復(fù)讀取時(shí)，直接從緩存中讀取。

上面是低成本的管理方法，基本幾臺(tái)服務(wù)器即可搞定，但是管理起來(lái)麻煩一些。

當(dāng)然，如果整體數(shù)據(jù)量特別大的話(huà)，也不在乎投入費(fèi)用的話(huà)，用集群吧，用TIDB吧