當專案上線後,隨著使用者的增長,有些資料表的規模會以幾何級增長,當資料達到一定規模的時候(例如100萬條),查詢,讀取效能就下降得很厲害,這時,我們就要考慮分表。
更新表資料時會導致索引更新,當單錶資料量很大時這個過程比較耗時,這就是為什麼對大表進行新增操作會比較慢的原因,並且更新表資料會進行表級鎖或者行鎖,這樣就導致其他操作等待。
所以我們將大表拆分為多個子表,那麼在更新或者查詢資料的時候,壓力會分散到不同的表上。由於分表之後每個表的資料較小,不管是查詢還是更新都極大的提高了速度,即使出現最壞的「鎖表」的情況,那其他表還是可以並行使用。
1.分表的策略
分表有多種策略:
(1)按使用者id分表,例如id為1-10000在表1,id為10001-20000在表2
(2)插入的時間分表
(3)按每個表固定記錄行數拆分
在專案,由於這個表是儲存使用者的通訊錄,為了保證乙個使用者的所有通訊錄資料都儲存在同乙個表,選擇的分表方式就是(1),按使用者id分表。
2. 分表策略確定下來了,還有乙個非常嚴重的問題,因為現在使用者的資料都分散在不同的表中,之前的業務功能如何保證呢?比如說我要插入一條記錄、更新一條記錄、刪除一條記錄、查詢統計資料,現在要怎麼處理呢?
如果分表的儲存引擎是myisam,這裡有一種很簡單的處理方法。利用merge儲存引擎將拆分的表合併成一張表。當然了,如果使用innodb,也能通過alter table命令把innodb變為myisam。
merge儲存引擎可以將n個子表聯合在一起,看成是乙個整表,實際上還是n個真實的子表。
3. 乙個例子
假設有表contact,儲存了9000個使用者的通訊錄資料,平均乙個使用者有聯絡人100個,那麼這個表的規模就達到了90萬條資料,我們需要對這個表分表。
下面的指令碼演示了怎麼在不關閉mysql服務的情況下對contact 分表
[sql]view plain
copy
-- ----------------------------
-- 建立根據原來的**式建立乙個臨時表,並把儲存引擎改為myisam
-- ---------------------------
create
table
contact_temp
like
contact;
alter
table
contact_temp engine = myisam
character
setutf8
collate
utf8_general_ci ;
-- ----------------------------
-- 建立分表contact_temp1,contact_temp2
-- ---------------------------
create
table
contact_temp1
like
contact_temp;
create
table
contact_temp2
like
contact_temp;
-- ----------------------------
-- 按使用者id分表,把id<5000 儲存在表1,id>=5000 and id<10000 儲存在表2,
-- ----------------------------
insert
into
contact_temp1
select
* from
contact
where
uid<5000;
insert
into
contact_temp2
select
* from
contact
where
uid>=5000
anduid<10000;
-- ----------------------------
-- 把原來的表改名,因為在mysql中不能有重複的表明,這樣子最終建立的merge引擎的表就能使用原來的表名
-- ----------------------------
rename table
contact
tocontact_bak;
create
table
contact
like
contact_temp;
-- ----------------------------
-- 先把原來刪除表上的主鍵的自增屬性去掉,再刪除主鍵
-- ----------------------------
alter
table
contact change `id` `id`
int(11);
alter
table
contact
drop
primary
key;
-- ----------------------------
-- 把錶的儲存引擎改為merge
-- ----------------------------
alter
table
contact engine=merge
union
=(contact_temp1,contact_temp2) insert_method=
last
; -- ----------------------------
-- 刪除所有的臨時表
-- ----------------------------
drop
table
contact_bak;
drop
table
contact_temp;
app後端設計 8 資料庫分表
當專案上線後,隨著使用者的增長,有些資料表的規模會以幾何級增長,當資料達到一定規模的時候 例如100萬條 查詢,讀取效能就下降得很厲害,這時,我們就要考慮分表。更新表資料時會導致索引更新,當單錶資料量很大時這個過程比較耗時,這就是為什麼對大表進行新增操作會比較慢的原因,並且更新表資料會進行表級鎖或者...
app後端設計 資料增量更新
因為分頁機制的存在,這個演算法實現起來是挺多需要注意的地方,下面我舉乙個簡化的例子詳細說明 一些假設 count 每頁的顯示條數 預設為3 page 當前頁碼 預設為1 since 時間戳,若指定此引數,則返回時間戳大於等於since的結果 應該是上次獲取的最新資料的update time max ...
app後端設計 資料增量更新
因為分頁機制的存在,這個演算法實現起來是挺多需要注意的地方,下面我舉乙個簡化的例子詳細說明 一些假設 count 每頁的顯示條數 預設為3 page 當前頁碼 預設為1 since 時間戳,若指定此引數,則返回時間戳大於等於since的結果 應該是上次獲取的最新資料的update time max ...