这个问题本质上和左连接的语义特性以及查询优化器的谓词下推规则有关，咱们一步步拆解分析，再给出可行的解决方案：

先明确问题根源 #

你的视图是t1 LEFT JOIN t2 LEFT JOIN t3，当执行SELECT * FROM v_test WHERE c5 = 0时，谓词下推的行为取决于c5属于哪张表：

1. 如果c5是t1的列：理论上优化器应该先过滤t1，再和t2/t3做连接，但如果t2/t3没有被下推过滤，可能是优化器没有把t1的过滤条件传递到关联表（毕竟t2/t3只需要匹配过滤后t1的c1值）。
2. 如果c5是t2或t3的列：WHERE c5 = 0会自动把左连接转换成等价内连接（因为左连接中不匹配的行c5为NULL，不满足=0），但优化器可能没识别到这个等价转换，导致只下推到t2/t3，而t1依然全量扫描。

针对性解决方案 #

情况1：c5是t1的列 #

• 手动引导优化器下推：改写查询语句，显式对t1做过滤，让优化器更容易把条件传递到关联表：

  SELECT * 
  FROM (SELECT * FROM t1 WHERE c5 = 0) filtered_t1
  LEFT JOIN t2 ON filtered_t1.c1 = t2.c1
  LEFT JOIN t3 ON filtered_t1.c1 = t3.c1
  

  这样t1会先过滤，t2/t3只会加载匹配filtered_t1.c1的行，相当于间接实现了谓词下推到所有表的Parquet文件。
• 检查优化器配置：确保你的SQL引擎开启了连接谓词传递的优化规则，比如Spark SQL的spark.sql.pushPredicateThroughJoin默认是开启的，如果被手动关闭了要重新打开；Trino的optimizer.push-predicates-through-joins也要保持启用状态。

情况2：c5是t2或t3的列 #

• 调整谓词位置或连接类型：
  • 如果你的业务逻辑允许（即只需要保留t1中匹配t2/t3且c5=0的行），可以把左连接改成内连接，优化器会自动把谓词下推到所有关联表：

    CREATE VIEW v_test as 
    SELECT * FROM t1 
    JOIN t2 ON (t1.c1 = t2.c1) 
    JOIN t3 ON (t1.c1 = t3.c1)
    

    之后查询SELECT * FROM v_test WHERE c5 = 0时，优化器会直接把c5=0下推到t2，并通过连接条件传递到t1和t3。
  • 如果必须保留左连接的语义（即保留t1中不匹配t2/t3的行，但过滤t2中c5≠0的匹配行），可以把谓词移到ON子句，并显式过滤t2：

    SELECT * 
    FROM t1
    LEFT JOIN (SELECT * FROM t2 WHERE c5 = 0) filtered_t2 
      ON t1.c1 = filtered_t2.c1
    LEFT JOIN t3 ON t1.c1 = t3.c1
    

    这样c5=0会直接下推到t2的Parquet文件，而t1和t3的加载也会基于连接条件优化。

通用优化建议 #

• 确保表有分区和最新统计信息：如果表按c1或c5分区，优化器能直接跳过不相关的Parquet分区；同时执行ANALYZE TABLE t1 COMPUTE STATISTICS（不同引擎语法可能略有不同）更新表统计信息，让优化器能准确判断下推的收益。
• 查看执行计划排查问题：用EXPLAIN命令查看查询的执行计划，比如EXPLAIN SELECT * FROM v_test WHERE c5 = 0，看看谓词被下推到了哪个环节，是否有统计信息缺失、优化规则被跳过等情况。

内容的提问来源于stack exchange，提问作者Joha