列式查询代码评审该盯住哪些细节ClickHouse 的问题常常在数据写入和表设计阶段埋下查询慢只是后果。代码评审应围绕实际访问模式检查写入是否过碎、分区是否可控、排序键是否服务于查询以及 JOIN 是否有可接受的资源边界。五个值得检查的点写入批量。小批插入会增加 part 数量和后台合并压力但合适批次取决于写入频率、分区和延迟要求。评审时应检查 part 指标、合并积压与重试行为而不是固定一条行数规则。分区键。分区用于数据生命周期和分区裁剪不是给每个查询建索引。按高基数字段分区会增加元数据与文件管理成本按天还是按月需要结合保留周期、写入量和删除方式验证。字段类型。LowCardinality、Enum或普通String的选择应以字段基数、更新方式和查询为依据。改类型前用真实数据比较磁盘占用、读取和聚合开销。排序键。过滤条件与ORDER BY的关系决定稀疏索引能否跳过数据。评审 SQL 时看常用过滤、时间范围与表的排序键并用EXPLAIN和 query log 验证读取量。JOIN。右表大小、分布方式、字典替代方案以及内存上限都要显式写清。不要用无依据的LIMIT掩盖语义问题若维表适合字典查询可先评估一致性和刷新要求。把规则放进 CI但保留人工判断静态检查可提示高基数分区、明显的小批写入和缺少过滤的查询。测试环境中的EXPLAIN能补充计划信息但数据规模与统计信息不同不能把它当作线上内存预测。规则应输出原因和修复建议并允许经过说明的例外。好的评审标准不是替代建模而是迫使每一条设计选择写出依据并能被验证。