Spark SQL列裁剪默认生效但需满足条件：元数据可推断且数据源支持；Parquet/ORC自动生效，CSV/JSON需显式传schema，JDBC需驱动支持pushdown，SQL中用*、UDF未标注返回类型或LATERAL VIEW未显式select会禁用裁剪。
Spark SQL 读取数据时默认会加载整行，哪怕你只用其中一两列——这在宽表或大字段（如 JSON、二进制）场景下会造成明显 I/O 和内存浪费。直接指定投影列（column pruning）是有效降低开销的第一步，而且 Spark SQL 原生支持，但需要满足特定条件才能真正生效。
spark.read.table() 或 spark.sql() 中列裁剪是否自动生效？
是，但仅限于**元数据可推断、且底层数据源支持列裁剪**的场景。比如 Hive 表（ORC/Parquet）、Delta Lake、以及部分 JDBC 驱动（需开启 pushdown）。而 text/csv 文件即使写了 select id, name from my_table，Spark 仍可能全量读取再过滤——因为 CSV 没有 schema 索引，无法跳过字段。
- Parquet/ORC：只要列名存在且类型匹配，
SELECT col_a, col_b FROM table会触发底层文件读取器只解码这两列 - CSV：必须显式设置
option("inferSchema", "false")+option("header", "true")+schema参数，否则无法裁剪 - JDBC：需确认驱动支持列 pushdown（如 PostgreSQL 的
useServerPrepStmts=true不影响裁剪，但必须避免fetchSize过大导致缓存整行）
使用 read.format().load() 时如何确保列裁剪生效？
关键在于把列信息“提前告诉”数据源，而不是依赖 SQL 引擎后期优化。对 Parquet/ORC，Spark 能自动完成；对其他格式，得靠参数或 schema 控制。
- Parquet/ORC：直接用
spark.read.parquet("path").select("a", "b")即可，无需额外配置 - CSV：必须传入
StructType并只包含目标列，例如schema = StructType([StructField("id", IntegerType()), StructField("name", StringType())])，再调用spark.read.schema(schema).csv("path") - JSON：同 CSV，不指定 schema 就无法裁剪；若用
multiline=True，更需注意 schema 必须完整覆盖嵌套路径中实际访问的字段
SQL 查询中哪些写法会意外禁用列裁剪？
表面看是投影，实则触发全列读取。常见陷阱包括：
- 用
*或table.*：哪怕后续WHERE只涉及一列，也会读全部字段 - UDF 出现在
SELECT中且签名含Row或未标注@udf(returnType=...)：Spark 无法判断其依赖哪些字段，保守起见加载整行 -
LATERAL VIEW explode(...)后没显式 select 子字段：例如SELECT explode(arr) AS x FROM t会读t全部列，即使只用x - CTE（WITH 子句）里用了
*，即使最终主查询只选几列，中间表仍全量读取
列裁剪不是银弹——它依赖数据源格式、connector 实现、以及 SQL 写法的配合。最容易被忽略的是 CSV/JSON 场景下不传 schema 导致裁剪完全失效，以及 UDF 使用不当引发隐式全行加载。真要压低 I/O，得从数据格式选型（优先 Parquet）、读取方式（显式 schema）、到 SQL 编写习惯（杜绝 *、拆分复杂 UDF）一起控制。
