optimize 命令重写数据文件，合并小文件、清理已删除数据，并可选执行 z-order 重排；它不优化查询本身，而是通过写放大改善后续读性能，但需合理配置 zorder by 及列选择才能提升过滤效率。
OPTIMIZE 命令到底在做什么
它不是“优化查询”，而是重写数据文件，合并小文件、清理已删除数据（基于事务日志），并可选触发 Z-order 重排。本质是写放大操作，耗资源但能改善后续读性能。
常见错误现象：OPTIMIZE 后查询没变快，甚至更慢——大概率因为没配 ZORDER BY，或列选择不合理。
- 只执行
OPTIMIZE不带ZORDER BY，仅解决小文件问题，对过滤性能提升有限 -
ZORDER BY列必须是高频过滤字段，比如user_id、event_date，而不是created_at这种高基数且不常用于 WHERE 的字段 - 对已存在大量碎片的表，单次
OPTIMIZE可能不够；Delta Lake 不会自动持续维护，需定期调度
Z-order clustering 实际效果依赖哪些条件
Z-order 不是银弹。它的加速效果高度依赖数据分布、查询模式和列基数。低基数列（如 status STRING 只有 3 个值）做 Z-order 几乎无效；而高基数 + 高过滤率的列（如 tenant_id）才真正受益。
使用场景：典型 OLAP 类查询，WHERE 中固定过滤 1–2 个核心维度，且结果集占比常低于 5%。
- Z-order 效果在 Parquet 文件级跳过（data skipping）上体现，不是引擎层索引，所以
SELECT *或全表扫描无收益 - Delta Lake 0.8.0+ 才完整支持 Z-order；旧版本即使写了
ZORDER BY也静默忽略 - 执行
OPTIMIZE ... ZORDER BY (col1, col2)时，col1和col2的顺序影响局部性，建议把选择性更高、过滤更严格的列放前面
对比真实查询耗时差异的关键指标
别只看“快了多少秒”，重点观察三个指标：文件扫描量（numFilesScanned）、字节跳过率（bytesSkipped / totalBytes）、以及 Spark UI 中的 “Scan Time” vs “Executor Compute Time”。Z-order 起效时，前者应显著下降。
性能影响示例：
-- 优化前 SELECT COUNT(*) FROM events WHERE tenant_id = 't-123' AND event_date = '2024-04-01'; -- 扫描 127 个文件，读取 2.1 GB <p>-- OPTIMIZE ZORDER BY (tenant_id, event_date) 后 -- 同一查询扫描 3 个文件，读取 84 MB
- 跳过率 > 90% 才算 Z-order 生效；若仅 30%~50%，说明数据分布太均匀，或 Z-order 列与查询不匹配
- 小表（
- 频繁写入的表，Z-order 效果衰减快——新写入的数据不在原有 Z-order 空间内，需配合
OPTIMIZE定期重排
容易被忽略的兼容性与副作用
Delta Lake 的 OPTIMIZE 是原子操作，但会生成新文件、更新事务日志，并可能触发下游消费任务失败——尤其当用 STREAMING 消费时，未处理好 version bump 可能丢数据。
- 启用 Z-order 后，
DESCRIBE DETAIL中的zOrderColumns字段可见，但不会自动暴露到元数据供 BI 工具识别，得靠人工维护文档 - 同一张表多次
OPTIMIZE ZORDER BY (a,b)不会报错，但重复执行浪费资源；建议加逻辑判断是否近期已执行过 - 如果表启用了
delta.autoOptimize.optimizeWrite = true，写入时会自动合并小文件，但**不触发 Z-order**——这是两个独立机制，别混淆
最麻烦的点其实是：Z-order 效果无法预估，只能实测。跑一次 OPTIMIZE 要几小时，验证查询要再跑几轮，中间还可能因数据倾斜卡住。得留足资源和回滚余地。
