本指南旨在帮助数据工程师与分析师优化在 TCHouse-X 上的查询性能。通过理解 Horn 自研优化器 的工作原理、掌握诊断工具及遵循最佳实践，您可以显著降低查询延迟并提升系统并发能力。
核心机制：统计信息与 CBO
TCHouse-X 的 Horn 优化器 采用基于成本的优化模型（CBO, Cost-Based Optimizer）。它通过分析表的数据量、列基数（Cardinality）及数据分布，决定最优的执行路径（如 Join 顺序、Broadcast vs Shuffle 策略等）。
警告：
没有统计信息，CBO 将无法生效，系统仅能回退到基础的规则优化（RBO），这通常会导致性能大幅下降。
统计信息收集 (COMPUTE STATS)
在创建新表、全量导入或增量数据变更显著后，必须手动收集统计信息，以防优化器因误判导致内存溢出 (OOM) 或全表扫描。
语法示范
-- 收集统计信息COMPUTE STATS customer;-- 查看表级摘要（行数、文件数、格式）SHOW TABLE STATS customer;-- 查看列级详情（基数、空值数、平均长度）SHOW COLUMN STATS customer;
何时需要重新收集
首次加载：数据入库后立即执行。
显著变更：当数据增量超过总量的 20% 时。
性能回退：原本正常的查询突然变慢，首选排查统计信息是否过期。
高级 SQL 优化最佳实践
编写准则
精简字段：严禁
SELECT *，仅读取必要列以减少 I/O 和内存占用。谓词下推：虽然 CBO 支持自动下推，但在复杂子查询中，显式添加过滤条件更稳健。
类型匹配：避免隐式转换（如
string_col = 123），这会导致索引失效及额外的 CPU 开销。Join 与聚合调优
大表 Join 小表：确保小表统计信息准确，优先触发 Broadcast Join。
倾斜处理：对存在大量
NULL 或热点值的 Join Key，建议先进行过滤或加随机盐（Salt）打散。去重策略：在高基数列上，
GROUP BY 的并行处理性能通常优于 DISTINCT。存储辅助
分区裁剪：查询条件必须包含分区键，避免全表扫描。
小文件治理：定期合并小文件，提升 Scan 阶段的吞吐量。
