靈活分庫分表，面試的時候這麼説，加分！详情 - 後端,分庫分表,分庫,分表,面試王中陽講編程日志

最近收到一位粉絲的提問，關於分庫分表在面試中如何結合業務邏輯舉例的問題。

他提到之前使用 serverless 數據庫時沒涉及分庫分表，現在遇到了具體場景，想請教合適的方案。

這其實是面試中很常見的考點，既要看技術思路，更要看能否結合業務落地，今天就藉着這個問題展開聊聊。

前言

怕有些朋友沒有了解過這方面的知識點，先來解釋一下這些概念：

分庫分表的核心目標：解決單庫單表因數據量過大（如千萬 / 億級）導致的「寫入慢、查詢卡、擴容難」問題；
分庫 vs 分表：分表是將一張大表拆成多張小表（同庫或跨庫），分庫是將數據分散到多個數據庫，兩者常結合使用；
為什麼結合業務？ ：分片策略（如按時間、按 ID）若脱離業務，可能導致「數據傾斜」（某分片數據過多）或「查詢效率低」（跨分片查詢頻繁），這也是面試重點考察的「業務落地能力」。

場景

比如有一個 “設備執行記錄表”，這個表數據的特點如下：

一天中存在早高峯和晚高峯（早上 8 點，晚上 7 點 —— 對應起牀和下班的時間）
整點和半點的時候存在極大值
數據是 insert 多，query 少
假設一天產生 100 萬條數據，早晚高峯分別產生 20 萬、15 萬條數據

粉絲提問

如何設計分庫分表？ 目前所能想到的方法是按照時間區間去分，比如把一天拆分成 24 份。我的思路是否可行？請問還有沒有更好的思路？

解答

“按照時間區間分，比如把一天拆分成 24 份” 基本可行，但結合業務特性可以進一步優化，讓方案更靈活且貼合實際場景。下面是我的思路，可以參考一下：

基礎時間分片（他的初始思路）

按 24 小時拆分確實能解決數據集中的問題，但需要注意：後半夜數據量很小（可能不足 1 萬條），如果嚴格按小時分表，會導致大量空表或小表，反而增加管理成本。這種方案適合數據分佈均勻的場景，但對 “早晚高峯突出” 的情況來説，不夠精細化。

具體實現時，可藉助分庫分表中間件（如 ShardingSphere）配置分片規則，例如：

分片鍵設為記錄生成時間（create_time）
分片算法採用時間範圍分片，表達式為 create_time BETWEEN '2024-07-31 00:00:00' AND '2024-07-31 01:00:00' 對應表名 device_log_20240731_00
需提前創建當日 24 張表，若用自動化腳本可減少人工操作

按高峯時段差異化分片

考慮到早 8 點、晚 7 點是高峯（分別產生 20 萬、15 萬條數據），可以將時段劃分為 “高峯區” 和 “非高峯區”：

早 7-9 點、晚 6-8 點作為高峯時段，單獨分表（比如拆成 “設備執行記錄_早高峯”“設備執行記錄_晚高峯”）；
其他時段（尤其是後半夜）合併分表，比如 “設備執行記錄_平峯”。

這種方式能避免小表冗餘，同時讓高峯數據集中存儲，方便後續針對性優化（比如高峯表用更高性能的存儲引擎）。

該方案需注意跨時段查詢問題，例如用户需要查詢某天 6-10 點的數據，會涉及早高峯表和相鄰平峯表。可通過中間件自動路由聚合結果，也可在應用層維護分片映射關係，查詢時先解析時間範圍再匹配對應表名。

按動態數據量分片（進階方案）

更靈活的做法是按數據量閾值分表，規則寫在配置文件中統一管理：

設定單表閾值（比如 20 萬條），當某時段數據達到閾值時自動創建新表；
例如早 8 點數據達到 20 萬，自動生成 “設備執行記錄_20240731_08_00”，後續數據寫入新表；
平峯時段數據量小，可能多個小時的數據合併到一個表中（比如 “設備執行記錄_20240731_平峯”）。

這種方案的優勢在於：完全適配 “insert 多、數據量波動大” 的特性，既不會因固定時段產生小表，也能通過配置靈活調整閾值（比如大促期間臨時調低閾值），運維成本更低。

具體落地可設計三層架構：

配置層：用 Nacos/Apollo 存儲閾值（如 single_table_max_rows: 200000）、表名生成規則（如 prefix + date + seq）
監控層：通過定時任務統計各表數據量，達到閾值時觸發分表事件
執行層：事件觸發後自動創建新表，並更新分片路由規則（無需重啓應用）

分庫分表後的查詢與運維考量

查詢優化

雖然該表 query 少，但仍需考慮極端場景。例如需查詢某設備一週的執行記錄，可通過以下方式優化：

建立全局索引表，存儲設備 ID 與對應分片的映射關係
對歷史冷數據（如超過 30 天）做聚合歸檔，減少查詢掃描範圍
高峯表單獨建立本地索引（如設備 ID + 時間），平峯表可省略索引降低寫入壓力

數據遷移與擴容

當單庫磁盤佔用達到 80% 時，需進行分庫擴容：

採用 “雙寫 + 校驗” 方案：先擴容新庫，寫入時同時寫新舊庫，讀請求仍走舊庫
通過校驗工具比對兩邊數據一致性，完成後切換讀路由，最後停寫舊庫
遷移過程中用流量控制確保不影響線上寫入性能（如限制每秒遷移 1 萬條）

面試時的加分表述技巧

上面這些思路其實是技術演進的過程，面試時可以這樣説：

我當時先考慮了最基礎的按小時分片，但發現會產生大量小表；接着結合高峯特性，設計了高峯 / 平峯差異化方案；最後考慮到業務可能變化（比如未來數據量翻倍），選擇了按動態數據量分片 —— 通過配置文件管理閾值，既適配當前 100 萬 / 天的規模，也能應對後續增長。整個過程是從‘解決問題’到‘靈活適配’的優化，最終方案既滿足性能需求，又降低了長期維護成本。

如果被追問如何處理異常場景，可補充：