mysql表數(shù)據(jù)量太大，達到了1億多條數(shù)據(jù)，除了分庫分表之外，還有沒有其他的解決方式？mysql在常規(guī)配置下，一般只能承受2000萬的數(shù)據(jù)量(同時讀寫，且表中有大文本字段，單臺服務(wù)器)?，F(xiàn)在超過1億，

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

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

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

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

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

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

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

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

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

前端工作量大還是后臺工作量大？

鄙人作為一個曾經(jīng)做了四年后端，一年半偽前端的工程師，來說句客觀的話。首先，我想說論技術(shù)棧復(fù)雜度來說，前后端都不淺，那些只懂后端的覺得前端就是一個兼容性的，還有只懂前端，覺得后端就是crud的，都是高估自己，低谷別人的人。一個人精力是有限的，每個技術(shù)路線可以深入的內(nèi)容又非常的多，一個程序員，其實大部分時間解決的，都是如何實現(xiàn)某種業(yè)務(wù)，如何優(yōu)化重構(gòu)古老的工程，特別是大廠里，螺絲釘不要高估自己的作用。

所以當(dāng)我們討論誰的工作多的時候，按照大概率的情況，基本沒區(qū)別。而你非得討論那些只有少數(shù)人，少數(shù)情況才需要面臨的問題，比如前端的跨端開發(fā)方案，如何磨平各端差異，如何克服動畫性能各端瓶頸，以及后端面臨的高并發(fā)，高可用性，數(shù)據(jù)庫分庫分表方案，緩存方案，安全策略，通信方案等等。面臨這些攻堅問題的人，都是那些少部分人解決的。市場上大部分人，要么是螺絲釘，要么是拿來主義，真的，誰也別瞧不起誰，大家都是打工人，工作內(nèi)容沒太大差別！

數(shù)據(jù)庫水平分庫和垂直分庫有什么區(qū)別？

常見的分庫方式有水平性和垂直性。一般來說，就是按照用戶屬性（地市或者ID的hash）進行分庫，或者按照業(yè)務(wù)功能塊進行分庫。水平分庫方式主要根據(jù)用戶屬性（如地市）拆分物理數(shù)據(jù)庫。一種常見的方式是將全省劃分為個大區(qū)。垂直分庫方式：根據(jù)業(yè)務(wù)維度和數(shù)據(jù)的訪問量等，進行數(shù)據(jù)的分離，剝離為多個數(shù)據(jù)庫。例如，將一些公用的配置信息存儲到一個數(shù)據(jù)庫中進行單獨維護。

當(dāng)數(shù)據(jù)庫扼住系統(tǒng)性能咽喉，直接分庫分表能解決嗎？

分庫分表是比較靠后的優(yōu)化手段，因為成本比較高。

遇到數(shù)據(jù)庫瓶頸:

- 首先考慮sql優(yōu)化，這是最簡單的方法。對現(xiàn)有系統(tǒng)基本沒有影響。

- 其次就是考慮數(shù)據(jù)庫的讀寫分離，這也是相對簡單的方法。在數(shù)據(jù)庫層面進行配置，系統(tǒng)層面只需要調(diào)整一下獲取數(shù)據(jù)庫連接的邏輯。讀數(shù)據(jù)時即可以獲取主庫連接，也可以獲取從庫連接。寫數(shù)據(jù)時只獲取主庫連接。

- 再考慮增加緩存層。將數(shù)據(jù)緩存到緩存中，當(dāng)再次訪問時不再從數(shù)據(jù)庫獲取。一般緩存層對系統(tǒng)是透明的，基本對系統(tǒng)本身沒有影響。但是引入緩存，也引入了相應(yīng)的需要考慮的問題，比如雪崩，命中率，分布式緩存等

- 還有一種非技術(shù)手段，就是改需求。引起性能問題的原因是否是需求不合理？或者需求太復(fù)雜？是否可以簡化需求？此方法對系統(tǒng)的影響也相對較小。

- 最后才考慮分庫分表。優(yōu)先分庫，因為相對分表更簡單。將對應(yīng)的表移動到新庫，調(diào)整系統(tǒng)獲取數(shù)據(jù)庫連接的邏輯。這里需要考慮要移動哪些表，在提高性能的前提下，首先盡量避免分布式事務(wù)。

- 最最后，考慮分表。分表的主要原因是單表數(shù)據(jù)量太大。分表又分縱切和橫切?？v切就是按列切，比如用戶表，常用信息為基本信息表，其它信息為詳情表。橫切就是按行切，比如一億數(shù)據(jù)量的表切分為十張一千萬的表。這里就涉及數(shù)據(jù)該存放到哪張表，或從哪張表里取。分表后又可以分庫，來進一步優(yōu)化。

- 如果涉及到分布式事務(wù)，又要考慮如何保證分布式事務(wù)。理論方面2pc，3pc，paxos，cap，base。對應(yīng)的中間件的使用。

對系統(tǒng)的設(shè)計和優(yōu)化不是人云亦云，需要根據(jù)實際的場景來進行處理。