Mycat 分表實戰：消息表 MySQL 分區 + Mycat 水平分庫雙層架構支撐百億級資料
社交應用的群聊訊息表面臨極大寫入量與歷史查詢需求。本文展示MySQL 原生 KEY 分區 + Mycat 水平分庫雙層切分架構，含建表分區策略、Mycat Schema/Rule 配置、全局 ID 生成技巧、擴容規劃與理論容量估算。
1. 業務場景與切分策略
- 群聊訊息：按
gid (群組 ID) 分區，組內訊息 ID 從 1 起遞增 (全局序列生成)，便於分頁查詢歷史。
- 單表分區 100 片 (KEY 分區)，Mycat 再按
user_id 模 10 分庫，部署 5 台物理機、每機 2 庫，共 10 分片。
- 雙層切分：單機文件數可控、跨機水平擴展靈活。
2. MySQL 分區建表
CREATE TABLE `group_msg` (
`id` BIGINT(20) NOT NULL,
`gid` BIGINT(20) DEFAULT NULL COMMENT '群組ID',
`content` VARCHAR(4000),
`create_time` DATETIME DEFAULT NULL,
PRIMARY KEY (`id`, `gid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8
PARTITION BY KEY(`gid`) PARTITIONS 100;
PARTITION BY KEY(gid)：MySQL 內部哈希分區，無需維護範圍邊界。- 主鍵包含分區鍵
gid，滿足分區表主鍵限制。
- 引擎用 MyISAM (範例)，生產建議 InnoDB + 適當分區數。
3. Mycat Rule 配置 (rule.xml)
user_id
mod-long
10
4. Mycat Schema 配置 (schema.xml)
select 1
5. 全局 ID 生成技巧
- Mycat 提供
MYCAT_SEQUENCE 全局序列表，應用端呼叫 SELECT NEXT VALUE FOR MYCAT_SEQ_GROUP_MSG 取得唯一 id。
- 每群組訊息 ID 從 1 起跳，
id 即代表該群組訊息總數，分頁查詢 WHERE gid=? AND id > last_id LIMIT 20 極其高效。
6. 容量估算與擴容規劃
| 層級 | 切分數 | 單片預估容量 | 理論總容量 |
|---|
| MySQL 分區 | 100 | 1,000 萬行 | 10 億行/庫 |
| Mycat 分庫 | 10 | — | 100 億行 |
- 日活 100 萬、人均 10 條/天 → 日增 1,000 萬行 → 理論支撐 2-3 年。
- 壓力增大時：先擴 Mycat 分庫至 20 片 (修改 rule count=20、新增 dataNode/dataHost)；再擴物理機至 10 台。
- 單機分區文件過多影響 OS 開啟文件數，雙層架構將單機文件數控制在合理範圍。
7. 運維優勢
- MySQL 分區管理單機內部文件，Mycat 管理跨機分片，職責清晰。
- 單機掛掉只影響該分片，Mycat 心跳檢測自動摘除，配合主從切換實現高可用。
- 避免單一巨大 MySQL 實例備份/恢復/ DDL 耗時過長。
「MySQL 分區 + Mycat 分庫」雙層切分，以成熟組件組合實現百億級訊息表的高效寫入、歷史分頁查詢與平滑擴容，是中大型社交/IM 系統的經典架構選型。
