1、索引優化和sql語句優化是必須的，避免模糊查詢和非索引查詢，刪改操作根據聚集索引進行，刪改操作太頻繁的話還是需要考慮分表
2、看需求，如果需求不限制，那就分表
分割槽會增加管理複雜度和成本這個很難理解，分割槽增加不了多少工作，如果需求要求必須單錶，分割槽是解決在千萬到幾億資料量的比較合適的方法
可能更大資料量還是要回到分的路上，但是可能更多考慮分布式
3、我們一般都是把歷史資料定期轉存其他表（一樣的表名後加年月例如table201205）歸檔~
這樣該錶本年度的查詢的壓力也小點（90%查詢量集中在本年度）,即使查詢歷史資料也不影響效能，強力推薦！
4、 （1）從結構上來說，分割槽很有必要，我聽過一些培訓，微軟給客戶的建議是乙個表如果大小超過50m，那就建議分割槽了。而且分割槽幾乎是「一次性」的事情，不會增加什麼管理成本。
（2）可以使用歸檔方式管理歷史資料。其實你的資料量不大啦，我以前做銀行系統，單錶就2億多，40g的大小。
（3）優化你的語句和設計。
（4）結合你的業務去晚上結構。有時候可以考慮用空間去換時間。
mysql 處理資料量較大的表
世界上並沒有完美的程式，但是我們並不因此而沮喪，因為寫程式就是乙個不斷追求完美的過程。mysql處理資料量較大的資料，可以採用元資料表的形式，使用元資料表來記錄表名，查詢時先查詢元資料表，根據元資料表找到要查詢的資料表，然後執行查詢。尤其是對於分表的情況是很有效的。乙個表，無論是垂直拆分還是水平拆分...
大資料量的處理
其實這個問題老是在面試的時候提到 1。建立專門的彙總表 這個表一般是每天晚上做統計處理 建立索引 索引的話，插入和修改會變慢，也是只做統計原因之一 用來查詢，如果量非常大，那麼分表，還是大，那麼分庫,就是資料倉儲概念了 2。關聯表查詢 多表聯合查詢 的大資料，首先就是1 把多個表做成乙個統計表，或者...
海量資料（資料量比較大時）的處理分析
海量資料 資料量比較大時 的處理分析 海量資料處理問題是一項艱鉅而複雜的任務。原因有以下幾個方面 一 資料量過大，資料中什麼情況都可能存在。如果說有10條資料，那麼大不了每條去逐一檢查，人為處理，如果有上百條資料，也可以考慮，如果資料上到千萬級別，甚至過億，那不是手工能解決的了，必須通過工具或者程式...