概述
以任務爲例，如果我們需要進行分表，需要關注兩點
1.數據增長量，決定了分表數量
2.查詢以及數據更新場景，決定了按那種方式分表
數據分析
1. 表結構
| 字段名 | 類型 | 描述 |
|---|---|---|
| id | long | 主鍵 |
| student_id | long | 學生id |
| teacher_id | long | 教師id |
| task_name | varchar | 任務名稱 |
| create_time | datetiem | 創建時間 |
| … | … | … |
2. 日任務量
均值：347348
| 日期 | 任務量 | 日期 | 任務量 |
|---|---|---|---|
| 2020-03-01 | 225925 | 2020-03-13 | 387824 |
| 2020-03-02 | 424014 | 2020-03-14 | 184733 |
| 2020-03-03 | 428069 | 2020-03-15 | 168003 |
| 2020-03-04 | 428821 | 2020-03-16 | 515914 |
| 2020-03-05 | 420984 | 2020-03-17 | 434955 |
| 2020-03-06 | 367536 | 2020-03-18 | 406467 |
| 2020-03-07 | 202577 | 2020-03-19 | 385732 |
| 2020-03-08 | 184836 | 2020-03-20 | 347008 |
| 2020-03-09 | 430492 | 2020-03-21 | 186037 |
| 2020-03-10 | 471406 | 2020-03-22 | 179031 |
| 2020-03-11 | 401931 | 2020-03-23 | 396231 |
| 2020-03-12 | 387274 | 2020-03-24 | 370556 |
3.月任務量
月均任務數：7901876
| 月份 | 任務量 |
|---|---|
| 2019年10月 | 5971953 |
| 2019年11月 | 7248057 |
| 2019年12月 | 9418330 |
| 2020年1月 | 5297569 |
| 2020年2月 | 10926496 |
| 2020年3月 | 8548852 |
4.月活用戶
月活用戶：225534
用戶月均任務：35
| 月份 | 活躍用戶數 | 月增長量 | 用戶平均增長量 |
|---|---|---|---|
| 2019-10 | 193368 | 5971953 | 31 |
| 2019-11 | 214237 | 7248057 | 34 |
| 2019-12 | 255763 | 9418330 | 37 |
| 2020-01 | 199287 | 5297569 | 27 |
| 2020-02 | 262315 | 10926496 | 42 |
| 2020-03 | 228235 | 8779162 | 38 |
場景分析
經過與產品確認，該表涉及的場景如下
教師端
1.教師佈置任務
2.教師撤銷任務
3.教師查看任務完成情況
學生端
1.學生查看任務列表
2.學生完成任務
通過使用場景可以看到對錶的操作都可以獲取到當前登錄用戶，顯而易見根據用戶id取模或者範圍分表，但是用戶id落到我們的任務表中確是兩個字段(student_id,teacher_id)，考慮到任務數據的高度聚合性，我們根據學校id分組。表中目前不存在學校id,所以需要教師端和學生端操作該表時根據當前用戶獲取到所屬學校id,由於用戶對應school_id相對不變，可以進行redis緩存，添加學校id對性能影響微乎其微。