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，而不是空值。

思路一：

思路二、修改索引：

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

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

2、將大表中的1000萬資料匯入建立的表中命令為

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

DELETE FROM 大表 LIMIT 10000000

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

不過如果問不想分庫分表的話，有一個辦法就是加記憶體，磁碟全部換固態，記憶體是用來查詢資料時防止獲取到的資料量過大而導致記憶體爆掉

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

除此之外還有什麼為了提高搜尋速度設定索引一類的，不過幾億的資料設定索引效果也不會太大。

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

tidb對伺服器硬碟要求太高了，要固態硬碟成本高，可以考慮用巨杉分散式資料庫（SequoiaDB）完全相容mysql

你這是上億元的問題，horizontal scaling 豈能是幾句就說清楚的？ 幾個問題要考慮 資料的不同資料中心的同步問題，冗餘問題， 個數據節點的cap三角問題。資料量一大必須拆分， 不然索引太大既不能載如記憶體，也無法快速查詢，插入刪除也成噩夢。

你不想分，就堆硬體堆頻寬唄。

單表資料上億可以採用以下方法

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

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

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

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

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

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

分庫最簡單的就是讀者分離，兩臺資料庫伺服器。

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

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

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

所以就得再業務層分庫了

最簡單的就是按地區分庫，訪問量高的地區都單獨使用伺服器，只儲存當前地區的資料，同時該地區資料也可以再分表，分庫。

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

一般大網站都是資料庫分散式，快取分散式，模組單獨部署，負載均衡，多節點，多種技術結合在一起的。

不過一億資料，分表和讀者分離，快取就解決了。

負載均衡

快取

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

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

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

3 表的大文字欄位分離出來，成為獨立的新表。大文字欄位，可以使用NOSQL資料庫

4 最佳化架構，或最佳化SQL查詢，避免聯表查詢，儘量不要用count(*), in，遞迴等消耗效能的語句

5 用記憶體快取，或在前端讀的時候，增加快取資料庫。重複讀取時，直接從快取中讀取。

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

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

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

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

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

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

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

看是業務系統還是報表查詢系統

如果是業務系統，考慮如下：

1.冷熱資料分離

待處理放在待處理庫或者快取

2.已經處理放在已處理庫或者資料倉庫

資料量還是大的話，考慮分割槽

目前使用分庫分表很痛苦，涉及誇庫連線、資料一致性會很頭疼，程式碼開發會變的很複雜 效能得不到保證

一億條看什麼表

有的表不用分

比如查詢索引最佳化良好 一億條沒啥事

如果欄位多多查詢複雜那就分

資料庫的型別目前有這麼幾種：關係型資料庫，nosql和最近出的newSql和時序資料庫。

能支撐大資料量又保有大部分的關係資料庫的功能，那非newSql資料庫莫屬了。

2012 年 Google 在 OSDI 上發表了 Spanner 的論文，2013 年在 SIGMOD 發表了 F1 的論文。這兩篇論文讓業界第一次看到了關係模型和 NoSQL 的擴充套件性在超龐大叢集規模上融合的可能性。

NewSql資料庫，國外的有CockroachDB，國內的有TiDB，TiDB有pingCap公司出品，國內的大公司已經在使用，有大公司的背書，所以我們公司也在使用，省去了使用mysql手工分庫分表和使用中介軟體的麻煩。

螞蟻金服 花唄借唄網商銀行大里攬收資深java開發人員, 工作地點杭州 北京 深圳，簡歷拋給我，郵箱 [email protected]

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

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

表設計的最佳化：在設計表的時候，就要考慮效能問題了。例如欄位儘量避免NULL，時間型別儘量使用TIMESTAMP，單表的欄位不宜過多等等。

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

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

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

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

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

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

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

軟體設計表資料量太大這個是架構設計裡，常遇到的問題。

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

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

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

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

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

這取決於你的資料，常見的有 2 種情況

這種表如果不想分庫分表，可以考慮生成中間資料表，把統計查詢結果按時間維度（例如小時、天、周、月）生成到中間表，查詢時直接查中間表

中間表基本能覆蓋查詢需求，並且查詢效能極大提升，偶爾需要查詢單條明細時，會落到原始表上，這時候一般查詢條件會命中索引，響應時間也可以接受

典型的比如使用者資訊表，儲存著使用者id，名稱，密碼，聯絡電話這樣資訊的表

其操作增刪改查都要支援，1 億多條記錄的情況下，最怕的就是範圍查詢和進入事務，如果不想分庫分表，建議上快取，比如 redis

資料量上億，如果全量快取記憶體佔用太大，所以要能識別出熱資料進行快取，比如使用者資訊表，可以考慮快取活躍使用者，例如最近一段時間登入過的使用者

另外，對資料的更新，也可以先更新快取，資料庫的更新可以非同步進行，比如透過訊息佇列來發送更新指令，避免資料庫操作瞬時的高併發

用快取對於非主鍵的、或者範圍查詢是比較無力的，這種資料其實分庫分表也不算是很好的解決方案，建議使用搜尋引擎，比如 es，solr之類