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

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

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

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

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

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

以上是一種低成本的管理方法，基本上幾個服務器就可以做到，但是管理起來有點麻煩。

當然，如果總的數據量特別大，并且您不關心成本，那么有四個主要缺點：1。無法存儲數據結構

2。即使只操作一列，也需要將整行讀入內存。表結構擴展不方便，模式固定

4。全文檢索功能支持較弱

針對以上四個缺點，提供不同的數據庫來解決問題。

1. K-V存儲不能存儲數據結構

以redis為例，值可以是數據結構，如字符串、哈希、列表、集合、sortedset、位圖等。列存儲可以解決在操作HBase

3表示的列

時，將整行讀入內存導致的高IO問題。文檔存儲可以解決mongodb

4表示的表結構擴展不方便的問題。全文搜索引擎解決了全文搜索功能的問題

以elasticsearch為例

以上解決方案雖然解決了關系數據庫的不足，但不能很好的支持acid功能。在某些場景下，關系數據庫是一個很好的選擇，因此這些數據庫只是關系數據庫的一個很好的補充，不能替代關系數據庫。

現(xiàn)在newsql也是大數據時代的一個發(fā)展趨勢，即可以支持事務，具有良好的可擴展性來支持大數據。以oceanbase、tidb和扳手/F1為例。

國慶節(jié)當天，中國螞蟻金融自主研發(fā)的金融級分布式關系數據庫oceanbase在被稱為“數據庫世界杯”的TPC-C基準測試中，打破了美國甲骨文公司9年來的世界紀錄，成為第一個登上榜首的中文數據庫產品。