1、首先考慮垂直拆分庫，不同的表拆分到不同的庫中，例如使用者庫、產品庫、支付庫；
2、然後考慮水平拆分庫，將乙個表的資料放到多張表中，例如按照使用者、時間、訂單號；
3、插入資料的時候不建立索引；
4、待資料已經插入完成後，建立索引；
5、正確的指定索引字段；
6、使用批量插入資料庫的方式代替單條資料的插入；
7、分表或者分庫以減少表的總量；
8、查詢只返回所需要的字段；
9、避免使用join操作；
10、where子句不進行null判斷，使用預設值代替，不使用!=、<>操作，不適用or，避免運算、函式、表示式的操作，這樣資料庫引擎會放棄索引，改為全表掃瞄；
11、當天的資料放在redis中，昨天的放到日表中，一周的放到周報表中，一月的放到月報表中，查詢的時候進行下鑽；
12、讀寫分離；
13、使用ssd固態硬碟；
14、資料收集->資料處理->資料建模->資料分析->資料視覺化；
15、快取主動更新方式，鎖控制、版本控制，版本控制分為單版本控制、多版本控制；
單版本控制每份資料儲存版本號，更新是傳入版本號並進行比較；
多版本控制每條資料儲存多分，每份有乙個版本號，不衝突，定期策略合併資料；
16、資料清理，應該歸檔或按照年存放，需要查詢時，才關聯歷史年度表；
大資料量處理
看看這個，異曲同工，永遠不超時 該程式是針對非常龐大的資料庫開發的，沒有用迴圈 用途 對過萬條資料的資料庫字段內容批量替換 資料庫連線 dim beeyee dbname,connstr,conn,intsn1 dim content,num,intsn,intidno,strcodea,strco...
mysql大資料量處理
2008 07 11 10 41 58 分類 mysql 舉報 字型大小訂閱 以下是個人的總結，有不對的地方大家指點 設計上 冗餘 有些能冗餘的就冗餘吧，盡量少關聯表 垂直分割槽，一條記錄中有text,varchar 這些能拆出來就拆出來，能用小的型別就用小的型別，如 char替換varchar之類...
大資料量的處理
其實這個問題老是在面試的時候提到 1。建立專門的彙總表 這個表一般是每天晚上做統計處理 建立索引 索引的話，插入和修改會變慢，也是只做統計原因之一 用來查詢，如果量非常大，那麼分表，還是大，那麼分庫,就是資料倉儲概念了 2。關聯表查詢 多表聯合查詢 的大資料，首先就是1 把多個表做成乙個統計表，或者...