请解释 Presto 查询优化器的内部工作机制，并说明在处理海量数据时如何实现对查询计划的有效优化？

回答思路

1. 【回答框架 1】Presto 查询优化器基于代价的优化（CBO）和规则优化（RBO）结合，将 SQL 解析为逻辑计划，再转化为物理执行计划。逻辑计划描述了关系代数操作，物理计划指定了执行细节，如 Join 算法、数据扫描方式等。
2. 【回答框架 2】RBO 应用一系列启发式规则，如谓词下推、列裁剪、常量折叠、限制下推等，提前简化查询。CBO 通过统计信息估算不同执行计划的代价，选择最优方案。统计信息包括表大小、列基数、数据分布等，对于连接顺序选择、Join 策略选择（广播 Join、哈希 Join）至关重要。
3. 【回答框架 3】对于大规模数据集，优化器根据表统计信息和集群资源，调整任务并行度，优化数据分区和排序，减少网络传输。动态过滤（Dynamic Filtering）能利用小表结果预过滤大表，降低 IO。此外，物化中间结果和缓存热点数据也能显著提升性能。
4. 【回答框架 4】实际优化中，需要注意维护统计信息的准确性，定期更新表分析。对于复杂的星型模型查询，优化 join 重排，避免数据倾斜，必要时手动调整会话参数，如设置 `join_distribution_type` 或使用提示（Hint）指导优化器。
5. 【关键点 1】Presto 优化器采用 RBO 与 CBO 结合，先规则优化后代价优化。
6. 【关键点 2】统计信息（如行数、基数）是 CBO 选择执行计划的核心依据。
7. 【关键点 3】动态过滤、分区裁剪、谓词下推等是应对大规模数据的关键优化手段。
8. 【关键点 4】连接顺序与 Join 策略（广播/哈希）的选择直接影响查询效率。
9. 【易错点 1】统计信息过时会导致 CBO 选择次优计划，需要定期分析更新。
10. 【易错点 2】过度依赖成本计算，忽略数据倾斜和集群实际负载，可能导致任务失败。
11. 【易错点 3】动态过滤并非总是有效，对于小维度表无益，反而增加开销。