韋德俊
你不想分，就堆硬件堆帶寬唄。
單表數據上億可以採用以下方法
首先分表是必須的，然後分庫。
分表可以採用按時間分，根據實際情況一個月或一個季度的分。
網站前端列表採用只查詢最新表
另外是按分類分，如果數據還是大則在分類基礎上再時間拆分。
然後配合緩存，再不需要及時更新的頁面所有查詢都只從緩存中查詢。
這時候還慢的話，就再分庫
分庫最簡單的就是讀者分離，兩臺數據庫服務器。
如果讀者分離還慢，就考慮再加多臺讀服務器。
程序上不想改動就採用負載均衡分攤壓力。
但是這樣還有個問題就是，每臺服務器都要保存一樣的數據，及時同步，數據量大維護挺麻煩。
所以就得再業務層分庫了
最簡單的就是按地區分庫，訪問量高的地區都單獨使用服務器，只保存當前地區的數據，同時該地區數據也可以再分表，分庫。
業務層要做的就是在訪問入口判斷用戶所在地區，然後訪問當前地區數據庫。像58同城這種帶地區分站的網站都是這種策略。
一般大網站都是數據庫分佈式，緩存分佈式，模塊單獨部署，負載均衡，多節點，多種技術結合在一起的。
不過一億數據，分表和讀者分離，緩存就解決了。
負載均衡
緩存
互加網絡科技
mysql在常規配置下，一般只能承受2000萬的數據量(同時讀寫，且表中有大文本字段，單臺服務器)。現在超過1億，並不斷增加的情況下，建議如下處理：
1 分表。可以按時間，或按一定的規則拆分，做到查詢某一條數據庫，儘量在一個子表中即可。這是最有效的方法
2 讀寫分離。尤其是寫入，放在新表中，定期進行同步。如果其中記錄不斷有update，最好將寫的數據放在 redis中，定期同步
3 表的大文本字段分離出來，成為獨立的新表。大文本字段，可以使用NOSQL數據庫
4 優化架構，或優化SQL查詢，避免聯表查詢，儘量不要用count(*), in，遞歸等消耗性能的語句
5 用內存緩存，或在前端讀的時候，增加緩存數據庫。重複讀取時，直接從緩存中讀取。
上面是低成本的管理方法，基本幾臺服務器即可搞定，但是管理起來麻煩一些。
當然，如果整體數據量特別大的話，也不在乎投入費用的話，用集群吧，用TIDB吧
Paul梅斯
分庫分表是最常規也是最常見的一種解決數據量過大的方式。分表的話也分為垂直分和水平分。下面我列舉一下其他的方式
1、讀寫分離。就是將數據庫的讀寫操作分開，比如讓主服務器讀，從服務器去做寫操作，或者讓性能比較好的服務器去做寫操作，性能不太好的服務器做讀操作；具體如何去讀寫分離，要看我們如何去分了。
2、靜態緩存。分為本地緩存和服務緩存，本地緩存就是將數據加載到本地，服務緩存就是比如使用Redis這樣的k-v數據庫進行存儲熱點數據。但是使用服務緩存也有缺點，最常見的問題就是，“擊穿”，就是假如緩存都失效了，這時候併發請求都去訪問db，此時可能造成服務器掛掉，這個時候為了避免這種情況，一般都是使用互斥量來解決這種問題。
3、系統架構。這個就要看我們整體項目的架構設計，主要是包括SQL操作的設計
張顧遠
中間件分庫分表唄，比如mycat sharing-jdbc ，前提是你別有複雜查詢。
程序猿老司機
不活躍數據同步數倉（有基礎設施支持的話）不行就單獨建歷史數據的庫洗過去，活躍數據做緩存，數據有共性可以搞分片庫多實例，然後用tidb做分片庫訂閱庫以支持複雜查詢，tidb性能不錯的
