先從查詢工作負載，而不是資料表結構開始
設計分割與叢集之前，我們通常先看一段具代表性的查詢紀錄：使用者最常依哪些欄位篩選、時間範圍通常多長、哪些查詢會進行大型關聯，以及哪些報表具有明確的回應時間要求。資料量很大，不代表每張表都需要複雜的實體配置；如果查詢總是讀取整張表，單純增加分割欄位也不會自動降低成本。
評估時要把查詢延遲、掃描量、並行需求與維護成本放在同一張圖上。互動式儀表板重視穩定而快速的回應，批次模型可能更在意總運算量，稽核查詢則可能需要跨越多年資料。不同工作負載若共用同一種設計，往往會讓其中一方付出不必要的代價。必要時應拆分服務層、建立彙總表，或讓批次與互動查詢使用不同的運算資源。
分割鍵要反映資料的讀取與生命週期
時間通常是事件表最實用的分割鍵，但要選擇正確的時間語意。若報表依交易發生日查詢，卻按照寫入時間分割，延遲到達或回補的資料就可能散落在不符合查詢條件的分割區。工程上應明確區分事件時間、處理時間與載入時間，並選擇最常出現在穩定篩選條件中的欄位。
分割粒度也不是越細越好。每日、每月或其他粒度，應由常見查詢範圍、每個分割區的資料量，以及歷史資料更新頻率共同決定。過細的分割會增加中繼資料與小檔案負擔，過粗則無法有效排除資料。若資料倉儲支援分割區到期、分層儲存或依日期刪除資料，分割策略也應配合保存政策，避免為了清理少量資料而重寫整張表。
- 優先選擇常被強制篩選的欄位：只有查詢真正帶入分割條件，分割裁剪才會發生。
- 避免用高基數識別碼直接分割：客戶編號、裝置編號或訂單編號容易產生大量極小分割區，通常更適合叢集。
- 考慮延遲資料與回補流程：確認寫入歷史分割區是否會造成額外重寫、鎖定或運算成本。
- 讓保存政策可以直接落在分割邊界：資料刪除與封存會更簡單，也較容易預估成本。
- 檢查資料傾斜：若少數分割區遠大於其他區域，查詢與維護時間仍可能不穩定。
用叢集處理分割區內的第二層存取模式
叢集、排序鍵或微分割的共同目的，是讓引擎在已選中的分割區內繼續排除資料。適合的欄位通常是經常出現在篩選、範圍條件或大型關聯中的欄位，例如租戶、地區、狀態或業務實體識別碼。欄位順序會影響效果，因此應依實際查詢組合決定，而不是把所有可能使用的欄位都加入。
叢集也有寫入與維護代價。持續串流、頻繁更新歷史資料，或資料天然亂序時，系統可能需要重新叢集、壓縮、整理或更新統計資訊。低基數欄位不一定能帶來足夠的資料排除，而過多叢集欄位則可能稀釋主要存取路徑。若查詢主要依聚合結果服務，預先彙總表或具體化檢視往往比持續調整底層排序更直接。
以可量測的成本模型持續驗證
上線前，應用代表性查詢比較新舊設計，並分開觀察掃描位元組、運算時間、排隊時間、快取命中與維護作業。不要只看單次最快結果；快取可能掩蓋資料裁剪不足，低流量測試也無法呈現正式環境的並行競爭。執行計畫應確認分割條件確實下推，型別轉換、函式包裝或時區處理沒有讓裁剪失效。
上線後則要監控查詢模式是否改變、分割區是否持續傾斜，以及重新叢集或資料重寫是否吃掉原本節省的運算成本。我們通常也會在語意層或查詢範本中要求必要的日期條件，並為無界線掃描設定治理規則。當效能問題來自錯誤的關聯、重複計算或過度明細化時，分割不是答案；先修正資料模型與查詢，再決定是否需要整合團隊協助調整整體資料管線。