1.拆分表資料
因為目前資料庫部分表資料快破億了，所以到了必須拆表的地步了，
把單錶比如biz_process目前7000萬的資料，按照時間段平均拆分到biz_process1,到biz_process18，每張表400萬，因為bat**單錶分割最好不超過500萬。
2.建立全域性拆表記錄表（sys_sub_table）
建立sys_sub_table欄位為id 表名 拆表最新序號 更新時間，然後先手動增加現在拆好的記錄進去，後面會按照每天的定時任務按照配置自動建表。
3.建立mysql建表儲存過程
建立對應分表的建表儲存過程，引數為表名和拆表序號名，以供後台每天定時任務呼叫。
4.系統資料字典配置biz_process表的分表引數
配置biz_process表分表引數為分表資料量例如500萬 100萬等 按照不同時候高潮期和冷淡期靈活配置資料量以便資料查詢達到最好效能。
5.新增建表定時任務
規則如下，定時每天24點統計全域性分表記錄表比如biz_process18的資料量多少，達到系統資料字典配置的分表記錄數比如500萬則呼叫儲存過程建立表biz_process19，這樣水平自動拓展。
6.查詢
查詢規則如下：按照時間段和其他附加條件查詢
1.確定要聚合查詢的表，通過時間段select count(*) from biz_process17 因為目前最新分表是 biz_process18，所說是biz_process17 如果為0 則不需要union all 否則繼續按照規則確定
biz_process16、biz_process15、biz_process14等表了，不過按照公司的資料量 1到幾個月範圍內查詢一般還不會出現聚合情況，因為每張表的拆表引數是400萬，如果出現了就按照此規則聚合查詢資料。
7.分表與分表之間關聯問題
分表與分表之間的關聯問題，其實也就是資料聚合異構，這個不管是用分庫分表中介軟體都會遇到這個問題而且根據業務複雜度比較難解決，因為要手動寫演算法去解決此種資料聚合問題，此設計在乙個庫內資料聚合查詢統計分析還是沒有什麼大問題。
資源如下:
msql用分表優化2億資料查詢速度
背景 需要給大約2億多的資料實現分頁展示查詢。實際效果 查詢速度一次大概要5分鐘 處理方式 1.換mysql資料庫引擎myisam myisam適合 1 做很多count 的計算 2 插入不頻繁，查詢非常頻繁 3 沒有事務。innodb適合 1 可靠性要求比較高，或者要求事務 2 表更新和查詢都相當...
海量資料庫的查詢優化及分頁演算法方案
create procedure pagination3 tblname varchar 255 表名 strgetfields varchar 1000 需要返回的列 fldname varchar 255 排序的欄位名 pagesize int 10,頁尺寸 pageindex int 1,頁碼...
海量資料庫的查詢優化及分頁演算法方案
如何在有著 1000 萬條資料的 ms sql server 資料庫中實現快速的資料提取和資料分頁。以下 說明了我們例項中資料庫的 紅標頭檔案 一表的部分資料結構 create table dbo tgongwen tgongwen 是紅標頭檔案表名 gid int identity 1,1 not...