Delta表Optimize操作跳过优化的原因排查

核心结论：列数过多不是导致Optimize被跳过的原因，以下是最可能的几类诱因： #

• 文件大小已达Optimize默认阈值
  Delta Optimize的核心目标是合并小文件，默认会将文件合并至接近spark.databricks.delta.optimize.maxFileSize（默认128MiB）的大小。你的表总大小25GiB、共200个文件，平均单个文件大小约128MiB，刚好匹配默认阈值。Optimize会判定当前文件大小已处于最优状态，因此直接跳过所有文件，不会生成新的合并文件，也不会在表历史中留下操作记录。

• Merge操作后生成的文件已符合最优标准
  每日执行的Merge（Upsert）操作本身可能已经生成了大小接近阈值的文件。如果Merge过程中Spark的分区、写入配置（如spark.sql.files.maxRecordsPerFile）设置合理，写入的文件会自动控制在合适大小，后续Optimize自然没有可优化的空间。

• Vacuum操作未残留需要合并的小文件
  每次Merge后执行Vacuum会清理旧版本的文件碎片，如果Vacuum彻底清理了所有因Merge产生的小临时文件或旧版本小文件，剩余的当前版本文件均为符合大小要求的文件，Optimize也就没有操作对象。

验证与排查建议 #

1. 查看当前文件的实际大小分布：执行DESCRIBE DETAIL <table-name>查看avgFileSize字段，确认是否接近128MiB。
2. 调整Optimize参数测试：手动指定更小的目标文件大小执行优化，比如：

   OPTIMIZE <table-name> ZORDER BY (<column-name>) FILESIZE 64MiB
   

   若此时有文件被合并，说明原文件大小确实达到了默认阈值。
3. 检查Merge操作的写入配置：确认spark.sql.files.maxRecordsPerFile、spark.databricks.delta.merge.repartitionBeforeWrite.enabled等参数是否影响了写入文件的大小。

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