mysql表數(shù)據(jù)量太大，達(dá)到了1億多條數(shù)據(jù)，除了分庫分表之外，還有沒有其他的解決方式？在正常配置下，MySQL只能承載2000萬數(shù)據(jù)（同時(shí)讀寫，表中有大文本字段，單服務(wù)器）?，F(xiàn)在已經(jīng)超過1億，而且還在

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

在正常配置下，MySQL只能承載2000萬數(shù)據(jù)（同時(shí)讀寫，表中有大文本字段，單服務(wù)器）。現(xiàn)在已經(jīng)超過1億，而且還在增加，建議按以下方式處理：

1子表。它可以按時(shí)間或一定的規(guī)則進(jìn)行拆分，以便盡可能地查詢子表中的數(shù)據(jù)庫。這是最有效的方法。特別是寫，放入一個(gè)新表，并定期同步。如果記錄不斷更新，最好將寫入的數(shù)據(jù)放在redis中，并定期同步表3的大文本字段，將它們分隔成一個(gè)新的獨(dú)立表。對(duì)于較大的文本字段，可以使用NoSQL數(shù)據(jù)庫

4優(yōu)化體系結(jié)構(gòu)，或者優(yōu)化SQL查詢，避免聯(lián)合表查詢，盡量不要使用count（*）、in、recursion等性能消耗語句

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

以上是一種低成本的管理方法，基本上幾個(gè)服務(wù)器就可以做到，但是管理起來有點(diǎn)麻煩。

當(dāng)然，如果整體數(shù)據(jù)量特別大，我們也不在乎投資成本，那就用集群和tidb吧

微聯(lián)盟事件可以說是對(duì)互聯(lián)網(wǎng)的沖擊！從威猛的官方公告中可以看出，數(shù)據(jù)庫數(shù)據(jù)是核心運(yùn)維人員故意損壞的。也就是說，這是一種人為的、有計(jì)劃的、惡意的破壞。

經(jīng)常掛在網(wǎng)民嘴邊的一個(gè)笑話是：“從入庫到刪庫都跑了”，沒想到今天成了現(xiàn)實(shí)。

然而，根據(jù)多年的互聯(lián)網(wǎng)行業(yè)經(jīng)驗(yàn)，這可能不是真正的人為破壞。首先，作案手法粗糙，到處留下“腳印”，似乎沒有計(jì)劃性和目的性。第二，在座的各位都不愿意用反復(fù)無常的沖動(dòng)換取數(shù)十年的監(jiān)禁。當(dāng)然，這只是一個(gè)討論。至于具體情況，我們要注意報(bào)道。

必須追究責(zé)任，但更重要的是防止事態(tài)惡化，防止事情再次發(fā)生。

這件事也給眾多互聯(lián)網(wǎng)公司敲響了警鐘！必須做好以下幾點(diǎn)：

1，備份！備份！備份。熱備和冷備應(yīng)足夠。

2. 做好權(quán)限控制，數(shù)據(jù)庫變更最好有流程審批流程。

3. 平時(shí)做好演練，一旦有事發(fā)生，應(yīng)該能夠迅速反應(yīng)和恢復(fù)。

4. 技術(shù)人員是公司的主力軍，請(qǐng)隨時(shí)給予優(yōu)待。

最后，?；ヂ?lián)網(wǎng)屆：四海升平，九州安定

微盟系統(tǒng)被員工刪庫，這事到底有多嚴(yán)重？相關(guān)各方將會(huì)面臨什么樣的處境？

現(xiàn)在很多公司的開發(fā)人員都應(yīng)該采用MVC架構(gòu)。

MVC是所謂的模型、視圖、控制器。

每一層都有明確的分工。

對(duì)于簡(jiǎn)單的項(xiàng)目，不管nignx如何，網(wǎng)關(guān)通常都會(huì)將請(qǐng)求從前端發(fā)送到后端，首先發(fā)送到控制器，然后發(fā)送到服務(wù)層，然后發(fā)送到Dao層。

這里的服務(wù)層就是所謂的業(yè)務(wù)層，專門負(fù)責(zé)業(yè)務(wù)處理操作，而Dao層則負(fù)責(zé)處理數(shù)據(jù)庫，將數(shù)據(jù)庫中的數(shù)據(jù)帶回服務(wù)，經(jīng)過服務(wù)處理后返回控制器層。控制器通過視圖解析器解析頁面，并通過瀏覽器呈現(xiàn)頁面。

基本上，我認(rèn)為答案是顯而易見的。也就是說，Java業(yè)務(wù)邏輯是在服務(wù)層編寫的。

事實(shí)上，服務(wù)層涉及接口和接口實(shí)現(xiàn)。

在編寫代碼時(shí)，我們通常為控制器定義一個(gè)調(diào)用接口。

實(shí)際上，服務(wù)接口的實(shí)現(xiàn)類應(yīng)該是編寫業(yè)務(wù)邏輯的地方。

當(dāng)然，許多公司可能有多個(gè)服務(wù)層，例如，有一個(gè)管理層繼續(xù)對(duì)數(shù)據(jù)進(jìn)行特殊的業(yè)務(wù)處理。這里只是一個(gè)簡(jiǎn)單的概述。

每個(gè)公司的每個(gè)項(xiàng)目根據(jù)其自身業(yè)務(wù)可能有不同的體系結(jié)構(gòu)。但本質(zhì)是一樣的。

綜上所述，業(yè)務(wù)邏輯必須作為一個(gè)獨(dú)立的層來處理，這樣便于擴(kuò)展和維護(hù)。記住不要在控制器中編寫所有業(yè)務(wù)邏輯。

每一層都有自己的分工，是捏合在一起的。代碼不僅冗長(zhǎng)，而且雜亂無章。

好吧，我希望我的回答能幫助你

！如果你有興趣，可以關(guān)注一下，一起學(xué)習(xí)交流！