列式查詢代碼評審該盯住哪些細節ClickHouse 的問題常常在數據寫入和表設計階段埋下查詢慢只是后果。代碼評審應圍繞實際訪問模式檢查寫入是否過碎、分區是否可控、排序鍵是否服務于查詢以及 JOIN 是否有可接受的資源邊界。五個值得檢查的點寫入批量。小批插入會增加 part 數量和后臺合并壓力但合適批次取決于寫入頻率、分區和延遲要求。評審時應檢查 part 指標、合并積壓與重試行為而不是固定一條行數規則。分區鍵。分區用于數據生命周期和分區裁剪不是給每個查詢建索引。按高基數字段分區會增加元數據與文件管理成本按天還是按月需要結合保留周期、寫入量和刪除方式驗證。字段類型。LowCardinality、Enum或普通String的選擇應以字段基數、更新方式和查詢為依據。改類型前用真實數據比較磁盤占用、讀取和聚合開銷。排序鍵。過濾條件與ORDER BY的關系決定稀疏索引能否跳過數據。評審 SQL 時看常用過濾、時間范圍與表的排序鍵并用EXPLAIN和 query log 驗證讀取量。JOIN。右表大小、分布方式、字典替代方案以及內存上限都要顯式寫清。不要用無依據的LIMIT掩蓋語義問題若維表適合字典查詢可先評估一致性和刷新要求。把規則放進 CI但保留人工判斷靜態檢查可提示高基數分區、明顯的小批寫入和缺少過濾的查詢。測試環境中的EXPLAIN能補充計劃信息但數據規模與統計信息不同不能把它當作線上內存預測。規則應輸出原因和修復建議并允許經過說明的例外。好的評審標準不是替代建模而是迫使每一條設計選擇寫出依據并能被驗證。