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