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

1 分表。可以按時間，或按一定的規則拆分，做到查詢某一條數據庫，盡量在一個子表中即可。這是最有效的方法

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

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

4 優化架構，或優化SQL查詢，避免聯表查詢，盡量不要用count(*), in，遞歸等消耗性能的語句

5 用內存緩存，或在前端讀的時候，增加緩存數據庫。重復讀取時，直接從緩存中讀取。

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

當然，如果整體數據量特別大的話，也不在乎投入費用的話，用集群吧，用TIDB吧

通常來說，Mysql表的數據量達到一兩千萬之后，操作起來開始有些吃力了，如果數據量達到上億，估計系統是吃不消的。

那么解決方案有哪些呢？我提幾個思路：

就用Mysql，不考慮遷移

• 分庫分表其實是比較好的方案，但是已經被題主否了，就不詳細說了；
  

• 表設計的優化：在設計表的時候，就要考慮性能問題了。例如字段盡量避免NULL，時間類型盡量使用TIMESTAMP，單表的字段不宜過多等等。

• 索引的優化：索引不是越多越好，也不是所有的字段都適合建立索引，使用多列索引的時候，要注意SQL中的條件順序等。

• SQL的優化：有的時候查詢慢，可能是SQL寫的爛。查詢盡量用到索引，避免錯誤的寫法導致索引失效，避免使用select *查詢出來所有的列，拆分復雜的SQL語句，查詢使用分頁等等。

• 分區：分區表是獨立的邏輯表，底層由多個物理表組成，這些對用戶來說是透明的；如果按照分區字段查詢數據的話，就會在某一張分區表內查詢，速度回比較快；分區字段的選擇，需要根據你們實際業務來；比如你們這張表如果可以分100個分區的話，那么每張表實際只有100萬的數據；使用分區表盡量避免全表掃描；建議考慮這種優化方式。

拋棄Mysql，遷移數據庫

• 如果公司有錢的話，可以直接上商業數據庫，Oracle、DB2什么的，一億的數據還是可以搞的定的，當然會也比較貴。

• 其他開源數據庫，有可以支持千萬級的產品，不過不建議使用，坑會比較多。

• 云數據庫，可以考慮把數據遷移到云上，比如ucloud云，花一些錢，少操一些；不過如果是比較敏感的數據，放到云上，多少會不太放心；私有云？這個也貴。

另外，如果不遷移Mysql的話，可以加以非關系型數據庫進行輔助，例如一些數據放到Redis里面進行緩存，或者通過跑數的方式，把原始數據加工好放到Mongodb中提供查詢，總之就是減少對數據庫的訪問。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

你不想分，就堆硬件堆帶寬唄。

單表數據上億可以采用以下方法

首先分表是必須的，然后分庫。

分表可以采用按時間分，根據實際情況一個月或一個季度的分。

網站前端列表采用只查詢最新表

另外是按分類分，如果數據還是大則在分類基礎上再時間拆分。

然后配合緩存，再不需要及時更新的頁面所有查詢都只從緩存中查詢。

這時候還慢的話，就再分庫

分庫最簡單的就是讀者分離，兩臺數據庫服務器。

如果讀者分離還慢，就考慮再加多臺讀服務器。

程序上不想改動就采用負載均衡分攤壓力。

但是這樣還有個問題就是，每臺服務器都要保存一樣的數據，及時同步，數據量大維護挺麻煩。

所以就得再業務層分庫了

最簡單的就是按地區分庫，訪問量高的地區都多帶帶使用服務器，只保存當前地區的數據，同時該地區數據也可以再分表，分庫。

業務層要做的就是在訪問入口判斷用戶所在地區，然后訪問當前地區數據庫。像58同城這種帶地區分站的網站都是這種策略。

一般大網站都是數據庫分布式，緩存分布式，模塊多帶帶部署，負載均衡，多節點，多種技術結合在一起的。

不過一億數據，分表和讀者分離，緩存就解決了。

負載均衡

緩存

很高興能夠看到和回答這個問題,作為一個悟空問答愛好者，我每天都在關注各個方面的消息，每天收獲也蠻多的。下面我將根據自己的經驗認真回答這個問題。

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

MySQL是世界上最受歡迎的開源數據庫。憑借其經過驗證的性能，可靠性和易用性，MySQL已成為基于Web的應用程序的領先數據庫選擇，被包括Facebook，Twitter，You Tube，Yahool等在內的知名Web財產所使用。

Oracle推動MySQL創新，提供了支持下一代Web，云服務，移動和嵌入式應用程序的新功能。MysQL是數據庫的相對控制系統。它將數據存儲在不同的表中，而不是存儲空間較廣，從而提高了速度和靈活性。

MySQL是最常用的訪問數據庫的語言。根據雙因素認證政策，MySQL軟件開發分為社區版和商業版。功率大、速度快、規模小、成本低，特別是使用開源數據庫，因為整個網站都是選用MySQL。

例如，MysQL為中小企業提供了比Oracle、DB2、SQL Server、SQL Server等個人用戶更多的機會。由于MySQL是開源軟件，這可能會大大降低整體成本。

Linux是操作系統，Apache或Nginx是Web服務器，MySQL是數據庫，PHP/Perl/python是服務器解釋器。由于這四種軟體都是免費或免費(FLOSS)的，所以應用這種方法可以不計成本地建立一個穩定的免費網絡系統LAMP或LNMP。

mysql數據庫本身是非常靈活的，這就導致了性能上的不足，嚴重依賴開發人員的能力。這就意味著開發人員的技術要高，mysql的性能要高。這也與很多數據庫類型有關，所以dba的工資通常較高。

為了避免表字段出現空值，空值難以優化，而且占用額外的索引空間，默認值為0，而不是空值。

mysql表數據量太大，達到了1億多條數據，我們該怎么辦呢？

思路一：

1. 用INT代替BIGINT，加上UNSIGNED(這樣體積會翻倍)，當然可以用TINT、SmalLINT和MEDIUM.inti更好。
2. 用列表或整數代替字符串類型
3. 使用TIMSTATIME代替DATETIME。
4. 表上的字段不要太多，建議20歲以下。
5. 保持IP的完整性

思路二、修改索引：

索引沒有更好的選擇，要看是否按要求創建索引。如果是，EXPLAIN可以通過討論中的命令和列中的命令來決定是使用索引還是完全掃描表。

1. 不能根據子程序中NULL的值來判斷，否則可能會導致引擎在完全掃描表時停止使用索引。
2. 值分布非常罕見的字段不適合做索引。例如，性別只有兩個重要區域。
3. 字符字段只包含前綴。
4. 字符字段不應該是主鍵。
5. 不要使用通過軟件連接的外部鍵。
6. 不要使用UNIQUE
7. 使用多行索引將保留搜索和條件序列，不必要的獨立索引將被刪除。

以上便是我的一些見解和回答，可能不能如您所愿，但我真心希望能夠對您有所幫助！不清楚的地方您還可以關注我的頭條號“每日精彩科技”我將竭盡所知幫助您！

碼字不易，感覺寫的還行的話，還請點個贊哦！

作為一名IT行業的從業人員，主要在從事產品研發及項目管理工作，在項目過程中，經常有優化數據庫存儲、架構方面的方案，所以我來探討一下這個問題。

目前經常使用的關系型數據庫如MySQL、SQL Server等，都是以“行”為單位進行存儲，為了快速檢索，也都采用了B樹或其他索引技術。

從原理上來講，表中的數據越多，索引樹的范圍越大，磁盤讀取也越多，性能也就越低。

從實踐角度來看，一般以百萬到千萬作為一個表的存儲量級，超出該范圍之后，性能就會下降，需要采用其他技術手段解決。

首先想到的就是能否將讀和寫分離，主數據庫用于寫入，讀數據庫（多個）用于對外提供查詢，通過數據復制的方式將主數據庫的數據同步到讀庫。該架構提升了數據庫的讀寫能力，但對于主數據庫的寫入能力依然沒法擴展。

其次，垂直分表就是把一個數據量很大的表,可以按某個字段的屬性或使用頻繁程度分類,拆分為多個表。如有多種業務類型，每種業務類型建立不同的表，tb1,tb2,tb3。如果日常業務不需要使用所有數據，可以按時間分表，比如說月表。每個表只存一個月的記錄。

再次，水平分表就是根據一列或多列數據的值把數據行放到多個獨立的表里，這里不具備業務意義。如按照id分表，末尾是0-9的數據分別插入到10個表里面。

這樣做的好處就是解決了數據存儲容量的問題，但也帶來了諸多弊端，不再一一闡述。

mysql優化的方式有很多，選擇上主要還是要考慮個人的實際情況，如代碼不可控的情況下，就不適合選擇按字段屬性分表的情況，這樣可能會帶來大量的重構以及很多不可預期的風險。

而架構的優化，雖然對應用是透明的，但對sql的寫法有很多局限性，比如說不能使用聚合函數等等，同時也需要有充足的硬件資源，只有一臺服務器的情況下是沒有意義的。

相比起來，代價最低的是按時間分表或分區，這兩種辦法對應用來說都是透明的。分區只需要一次本地數據遷移的操作。而通過分表把現網數據和歷史數據分離，唯一的代價是定期的數據維護。

一般如果表里面有1億數據的情況下，索引的問題應該是常識了，這方面我就不說了。

在做垂直拆分或者水平擴展的時候，要大概清楚2億條數據庫是都經常性進行大規模的查詢還是更新？這決定了你擴展的思路，如果是范范的進行擴展，有時候會起到適得其反的效果。

1.首先要檢查哪些經常查詢的SQL是否可以有優化的地方，檢查數據庫的索引建立的是否合理，索引是否有效，可以嘗試建立分區表等，這一步主要是單個數據庫的優化。

2.在mysql的擴展上包括垂直拆分，即分庫分表的，這種需求需要在代碼層實現，需要開發人員在代碼層進行一些配置。這個可以起到寫的負載均衡。而水平擴展說白一點就是增加服務器的個數，由原來的一臺變成幾臺，再通過mysql的中間件，比如proxysql或者mycat進行一些配置（推薦proxysql），把寫請求放在那些性能好的服務器上，把讀分散到不同的服務器上，這樣就起到了讀的負載均衡。

3.如果上面垂直拆分或者水平擴展還是不能解決問題，可以考慮使用nosql，在前端增加一個緩存，memory cache或者redis來增加緩存，應用層在首先會讀取redis里的數據，如果沒有才會往MySQL里去讀，當然你的查詢不能是太過復雜的查詢。個人推薦redis，畢竟它可以磁盤落地化。

綜上所述，應該可以解決問題。當然這里只是提供思路，沒有一種方案是完美的，都需要根據需求去定制。

軟件設計表數據量太大這個是架構設計里，常遇到的問題。

先考慮優化，讀寫分離、合理索引、緩存數據、高頻讀取寫進redis等產品，也可以買非常多的實例來做負載，不過這些操作撐不了多久。 分庫分表幾乎是唯一的，也是最好的辦法。

當然分庫分表大家不愿意操作，主要還是因為要改動業務代碼，還有一種傻瓜式操作，不需要你改業務代碼，那就是分區，例如你把數據一個月分一個區，數據庫 mysql 單表數據量達到千萬、億級，可以通過分表與表分區提升服務性能。

不過你說不想分庫分表，那就拿錢抗啊,上商業數據庫，Oracle、DB2、PGSQL等,即使上這些數據庫，你遲早還是得根據業務分庫分表，這個你可以問下頭條，淘寶，知乎這些大量數據的工程師，長期下去分庫，分表是唯一出入。

你看京東，淘寶你的訂單數據就知道了，默認顯示三個月， 有可能他們就是定義最近三個月為熱數據，當前常用庫，之前你的訂單在歷史數據庫里面。這樣的好處，顯而易見的，你的系統查詢速度最大的影響因素，就是數據量。

這就像一個箱子里面裝了100人，只能從上面往下面看找人， 如果你有1000人，做成10層的箱子， 要去箱子里面找出5個穿紅色衣服的人很慢。 如果分成10個箱子，即使查找10次，也比在一個箱子里面快。

架構里面雖然沒有什么唯一的解決辦法，遇到大數據，思路基本都是統一的，減少源站數據庫訪問，分庫分表。

請問你描述的這個問題說的是我么？【哭臉】很不湊巧，由于預計錯誤本來計算大概有800多萬的數據，最終處理完共計4億9千多萬【后面的零頭我甚至不想說了】,一張表4億多的數據，用的自增id幸虧id沒有爆，不幸中的萬幸透露著另一個不幸就是，因為這臺裝有mysql的服務器上數據量很大，在我往里插入數據的時候在插到4億多的時候磁盤滿了，一點空間都沒有了，驚不驚喜意不意外【哭笑臉】,因為這個數據屬于一次性的數據，用于進行深度學習所需的訓練數據，但是讀的壓力也很大，隨便一個select7分鐘起步~~~~

難難難啊！最后我的解決辦法就是刪除了當前服務器上的一部分日志，讓mysql可以動起來，然后將數據按1000萬一個的導成小表，然后把大表數據刪除，步驟大概是

1、新建一個表結構一致的表后綴按照xxx_0,xxx_1 等方式命名

2、將大表中的1000萬數據導入創建的表中命令為

INSERT INTO `小表_01` (`xxx`) (SELECT `xxxx` FROM `大表` LIMIT 0, 10000000)

3、刪除掉大表中前1000萬條數據

DELETE FROM 大表 LIMIT 10000000

我是按照上面的步驟搞得，會大大減少操作表所需的時間

不過如果問不想分庫分表的話，有一個辦法就是加內存，磁盤全部換固態，內存是用來查詢數據時防止獲取到的數據量過大而導致內存爆掉

換固態則會為數據的插入和讀出提高速度。

除此之外還有什么為了提高搜索速度設置索引一類的，不過幾億的數據設置索引效果也不會太大。

最終，建議還是不要叫一張表數據量超過1000萬，會導致出現各種問題，如果超了最方便的辦法就是分庫分表。

以上希望能對題主有幫助~~~~~~

一億數據其實也不算太大，分庫分表主要是解決以前mysql不支持online ddl，現在的版本很多都支持online了，即使一些少見操作不支持online 也有解決辦法，分表之后，應用復雜了。

下面，我將用2分鐘的時間，與您深入探討，mysql表數據量達1億多條時，應該采取什么措施，如果您有不同的見解，可以在評論區與我交流。(文末有免費福利)

如果你不嫌麻煩，或不計成本，請看以下幾個方法

方法一：換機器，加硬盤，加內存。

方法二：聘請一個數據顧問。

方法三：看數據增量，每行數據的大小，一億數據，如果操作簡單的話，也不是沒法處理。

方法四：一億多都是需要的記錄么？對于不需要的記錄，可以定時歸檔。

方法挺多，但都要根據情況細分，有點兒麻煩。

如果你想走捷徑，拿來即用，那么請看這里

用云表內嵌的MySQL數據庫，其研發團隊一直在升級維護MySQL，性能得以優化，存儲一億數據量，不是問題。

因為專業且強大，所以MySQL是90%的企業都會選擇的數據庫。

如果你覺得不合適，那么你也可以根據云表的幫助文檔，設置成sql server，Oracle數據庫。

我們都知道數據庫的作用巨大，正是因為有了數據庫，我們可以直接查找數據。

例如你每天使用余額寶查看自己的賬戶收益，就是從數據庫讀取數據后給你的。

你的銀行卡賬號，密碼里面的RMB等等都是查詢的數據庫。

之所以建議你使用云表內嵌的MySQL數據庫，是因為，通過云表，還可以與企業微信、釘釘、用友金蝶、浪潮等第三方系統進行對接。

而MySQL數據庫作用范圍下的，erp，oa，wms，商業智能（BI），進銷存等各類業務應用，通過它也是可以開發出來的。

并且開發出來的業務應用，秉承了MySQL語句增刪改查的特性。

沒錯，用云表開發出來的業務應用，功能是隨時可以增刪查改的。

事實上，云表就是一個“辦公軟件+開發工具”。

由于云表內嵌了MySQL數據庫的原因，所以通過它可以進行復雜的數據運算，如數據透視，數據分析等，億級數據，秒級響應。

還可以對它設置精確到行列的權限管控，進行工作流，流程審批，多人協同等工作。

當然啦，其他大大小小的業務，也是可以解決的。

比如說制作報表看板，H5頁面生成，掃碼出入庫，與API接口進行對接，封裝PDA，鬧鐘提醒，群發信息，生成移動端app......

像許繼電氣，中冶，中鐵，香港建滔集團，南方物流，燕山大學等，都在使用它。

可以免費使用

目前，云表是有提供永久免費版本的。

內嵌的MySQL數據庫，數據安全不丟失

它的數據存儲方式有：本地部署，云端部署，混合部署等多種部署方式。

也就是說，云表不僅內嵌了MySQL數據庫，而且還保證了數據的安全。

篇幅所限，就說到這里。

高山流水，終須一別。免費的軟件獲取方式在此奉上。

1. 點贊+評論+轉發

2. 關注我，點擊我的頭像，私信給我發送：cc

如果不是特別必要，我建議還是不要瞎折騰，不然數據庫沒搞好，還會添一堆麻煩事兒！

分庫分表是最常規也是最常見的一種解決數據量過大的方式。分表的話也分為垂直分和水平分。下面我列舉一下其他的方式

1、讀寫分離。就是將數據庫的讀寫操作分開，比如讓主服務器讀，從服務器去做寫操作，或者讓性能比較好的服務器去做寫操作，性能不太好的服務器做讀操作；具體如何去讀寫分離，要看我們如何去分了。

2、靜態緩存。分為本地緩存和服務緩存，本地緩存就是將數據加載到本地，服務緩存就是比如使用Redis這樣的k-v數據庫進行存儲熱點數據。但是使用服務緩存也有缺點，最常見的問題就是，“擊穿”，就是假如緩存都失效了，這時候并發請求都去訪問db，此時可能造成服務器掛掉，這個時候為了避免這種情況，一般都是使用互斥量來解決這種問題。

3、系統架構。這個就要看我們整體項目的架構設計，主要是包括SQL操作的設計