10 性能调优：小文件合并、缓存与统计信息维护

摘要

Delta Lake 的查询性能瓶颈通常来自三个方向：小文件问题（大量小 Parquet 文件导致 S3 请求数爆炸、Driver 内存耗尽于文件列表管理）、缓存未命中（热点数据反复从 S3 读取，未利用本地缓存）、统计信息缺失（Spark CBO 在缺乏准确列统计时做出错误的 Join 顺序/策略选择）。本文围绕这三个方向，系统讲解 Delta Lake 的性能调优工具链：小文件合并（手动 OPTIMIZE、Auto Optimize 的 Optimize Write 和 Auto Compaction 两种模式，以及目标文件大小的权衡）、Delta Cache（与 Spark RDD Cache 的本质区别——Delta Cache 是 SSD 级别的透明列式缓存，Spark Cache 是内存级别的行式缓存）、统计信息维护（ANALYZE TABLE 收集表/列级别统计供 CBO 使用，以及统计信息过期的判断标准）。三者共同构成 Delta Lake 生产环境的性能维护体系，任何一项缺失都可能导致查询性能大幅下降。

第 1 章小文件问题：Delta Lake 的慢性病

1.1 小文件是如何产生的

在 Delta Lake 中，以下场景会持续产生小文件：

场景一：高频 Streaming 写入

每次 Structured Streaming 微批（如每 30 秒一批）都会写入若干个新 Parquet 文件。一天 2880 个微批，每批 10 个文件，一天就积累 28800 个文件。每个文件只有几 KB 到几 MB（30 秒内的数据量）。

场景二：高并发小批量 MERGE

CDC 同步场景中，每分钟一批变更数据，每批涉及几千行的 UPDATE。CoW 模式每次产生若干个新 Parquet 文件，且被修改的文件被重写成新文件——文件数量快速增加，但每个文件的有效数据量（排除被删除行后）减少。

场景三：过细粒度的分区

按 date + hour + region（3 个维度）分区时，如果某些分区的数据量很少（比如深夜低峰时段的某个地区），该分区目录下只有 1-2 个很小的 Parquet 文件。分区设计过细本质上就是强迫数据碎片化。

1.2 小文件的危害

危害一：查询变慢（Driver 侧元数据处理）

读取 Delta 表时，Driver 需要加载 Delta Log 确定所有有效文件，然后将文件列表分配给 Executor。当文件数量达到数十万时：

Delta Log 解析本身就很慢（需要合并大量 JSON Action）
Driver 内存压力增大（文件列表占用内存）
每个 Parquet 文件分配为一个 Task，数十万个小文件 = 数十万个 Task = Task 调度开销淹没实际计算

危害二：S3 请求成本高昂

AWS S3 按请求数计费（PUT/GET 各 $0.005/1000 请求）。读取 100 个 1GB 文件 vs 读取 100000 个 1MB 文件，实际数据量相同，但后者的 S3 GET 请求数是前者的 1000 倍，成本高出 1000 倍。

危害三：压缩率下降

Parquet 文件的列式压缩（Snappy/Zstd）在数据量越大时效果越好（更多重复值可以被压缩）。几 KB 的小文件几乎无法利用压缩，存储成本是等量大文件的 3-5 倍。

1.3 手动 OPTIMIZE：按需合并

-- 合并整个表的所有小文件（不带 ZORDER，只做文件合并）
OPTIMIZE orders;
 
-- 合并特定分区（生产中常用：只合并昨日的新数据）
OPTIMIZE orders WHERE order_date = date_sub(current_date(), 1);
 
-- 合并 + Z-Order 排序（同时解决小文件和查询加速）
OPTIMIZE orders WHERE order_date = date_sub(current_date(), 1)
ZORDER BY (customer_id, product_id);

OPTIMIZE 的目标文件大小：默认目标是 1GB（delta.targetFileSize = 1073741824）。这个值的选择有工程权衡：

目标文件大小	优势	劣势
小（128MB）	分区裁剪粒度更细，部分更新代价较小	文件数量多，Driver 元数据压力较大
中（512MB）	平衡，通常适合 OLAP 场景	—
大（1GB，默认）	文件数少，Driver 压力小，压缩率高	单文件读取时间长，并行度低
超大（2GB+）	—	S3 的 5GB 分片上传限制；单文件损坏影响大

实践建议：中等大小表（GB 级分区）用默认 1GB；超大表（TB 级分区）可考虑 512MB 以提高并行读取效率；流式写入的中间表可适当减小到 256MB（减少单次 OPTIMIZE 的 Shuffle 数据量）。

第 2 章 Auto Optimize：自动化小文件治理

2.1 为什么需要 Auto Optimize

手动 OPTIMIZE 的问题是需要人工干预——在高频写入场景（每分钟写入一批数据），每次写入后都需要判断”是否需要 OPTIMIZE”，这不现实。Auto Optimize 将文件合并逻辑嵌入写入路径，对写入方透明，自动防止小文件积累。

Delta Lake 的 Auto Optimize 由两个相互独立的特性组成：Optimize Write 和 Auto Compaction，两者解决不同阶段的小文件问题。

2.2 Optimize Write：写入时就避免小文件

Optimize Write 在写入 Parquet 文件时，自动对数据进行重新分区，确保每个输出文件接近目标大小（默认 128MB per file，注意这里的目标大小比 OPTIMIZE 的 1GB 小，因为是写入时的实时优化）。

不使用 Optimize Write 时的小文件产生过程：

Spark 写入配置：spark.sql.shuffle.partitions = 200
写入数据量：20MB（一次小批量 MERGE 的新数据）

Spark 的行为：
  200 个 Shuffle 分区 → 每个分区约 20MB/200 = 100KB
  输出：200 个 100KB 的小文件！
  （即使写入的总数据量只有 20MB，也会产生 200 个文件）

使用 Optimize Write 时：

Optimize Write 分析写入数据量（20MB）和目标文件大小（128MB）：
  目标文件数 = ceil(20MB / 128MB) = 1 个文件
  自动将 200 个 Shuffle 分区合并为 1 个输出文件（通过 coalesce）
  输出：1 个 20MB 的文件
  （文件数从 200 个减少到 1 个）

配置方式：

-- 表级别开启 Optimize Write
ALTER TABLE orders SET TBLPROPERTIES (
    'delta.autoOptimize.optimizeWrite' = 'true'
);
 
-- 或 Spark Session 级别（影响所有 Delta 写入）
SET spark.databricks.delta.optimizeWrite.enabled = true;
 
-- 开源 Delta Lake（非 Databricks）的等价配置
SET spark.sql.adaptive.enabled = true;  -- AQE 会自动合并小分区

核心概念

Optimize Write 的实现原理：Optimize Write 并不是简单的 coalesce（只减少分区数，但分区之间数据量可能不均匀）。它实际上是基于数据量的自适应重分区：分析每个 Shuffle 分区的数据大小，将数据量小的相邻分区合并（类似 AQE 的 Coalesce Partitions 功能），同时对数据量大的分区进行 split（避免单个文件过大）。这使输出文件的大小分布更加均匀，接近目标文件大小。

2.3 Auto Compaction：写入后的自动合并

Auto Compaction 在每次成功写入后，自动检查当前分区是否存在过多小文件，如果超过阈值（默认：分区内文件数 > 50 且平均文件大小 < 目标大小的 1/2），自动触发一次轻量级的 OPTIMIZE（不做 Z-Order，只做文件合并）。

写入流程（开启 Auto Compaction 时）：
  t=0: Spark 写入 10 个新小文件到 partition=2026-01-15
  t=1: Delta Log 提交成功
  t=2: Auto Compaction 检查 partition=2026-01-15 的文件状态：
       当前文件数：65 个，平均大小：15MB（< 目标 1GB/2=512MB）
       触发条件满足！
  t=3: 后台异步触发 OPTIMIZE（合并 65 个小文件为 1-2 个大文件）
  t=4: 合并完成，Delta Log 写入新的 add/remove Actions

Auto Compaction 的关键特性：

异步执行：不阻塞当前写入作业
轻量级：不做 Z-Order，只做文件合并，开销较小
自适应阈值：根据当前分区文件状态动态判断是否需要合并

-- 开启 Auto Compaction
ALTER TABLE orders SET TBLPROPERTIES (
    'delta.autoOptimize.autoCompact' = 'true'
);

2.4 Optimize Write vs Auto Compaction 的协同

特性	Optimize Write	Auto Compaction
触发时机	写入过程中（同步）	写入成功后（异步）
适用场景	防止写入时产生小文件	修复已存在的小文件
Z-Order	不支持	不支持（需要手动 OPTIMIZE ZORDER）
代价	增加写入延迟（额外的重分区 Shuffle）	额外的后台 I/O
效果	写入时就是大文件	定期合并历史小文件

推荐组合：同时开启两者，Optimize Write 防止新小文件产生，Auto Compaction 清理历史遗留的小文件。Z-Order 排序则通过定期的手动 OPTIMIZE ZORDER BY 实现（不宜太频繁，因为 Z-Order 的全局排序代价较高）。

第 3 章 Delta Cache：透明的列式数据缓存

3.1 Spark Cache vs Delta Cache：两种截然不同的缓存

很多 Spark 工程师在切换到 Delta Lake 后，习惯性地使用 spark.read.format("delta").load(...).cache() 来缓存热点数据，但这种方式在 Delta Lake 场景下并不是最优选择。理解 Delta Cache 与 Spark Cache 的本质区别，是做出正确缓存策略决策的前提。

Spark Cache（DataFrame.cache() / persist()）：

# Spark Cache 的工作方式
df = spark.read.format("delta").load("s3://bucket/delta/orders/")
df.cache()  # 缓存 DataFrame 的计算结果（内存中的 Java/Scala 对象）
df.count()  # 触发缓存物化
df.filter("amount > 100").show()  # 从内存缓存读取，不走 S3

存储位置：JVM Heap 内存（MEMORY_ONLY）或 JVM + 磁盘（MEMORY_AND_DISK）
格式：行式（Java/Scala 对象，或序列化的二进制行）
粒度：缓存整个 DataFrame 的所有列（即使查询只需要部分列）
生命周期：Spark Session 级别，作业结束后缓存失效
局限性：跨作业不共享；缓存的是处理后的数据（列过滤、Schema 投影后），不是原始文件数据

Delta Cache（也叫 Databricks IO Cache）：

Delta Cache 是 Databricks 平台在计算节点的 SSD 磁盘 上透明缓存 Parquet/Delta 文件的机制——首次读取某个 Parquet 文件时，将文件数据写入本地 SSD（解压后的列式格式），后续读取相同文件时直接从 SSD 读取，不走 S3。

存储位置：本地 SSD（容量远大于内存，通常 TB 级）
格式：解压后的列式格式（类 Arrow 格式，可直接用于向量化读取）
粒度：Parquet 文件级别（缓存整个文件，但读取时仍只解码需要的列）
生命周期：跨 Spark Session、跨作业持久（只有 LRU 满时才淘汰）
透明性：对用户代码完全透明，无需任何代码修改

两种缓存的对比：

维度	Spark Cache	Delta Cache
存储层	JVM 堆内存	本地 SSD
容量	受 Executor 内存限制（GB 级）	SSD 容量（TB 级）
格式	行式/序列化对象	列式（Arrow 格式）
跨作业共享	❌ 不共享	✅ 共享
代码侵入	需要显式 `cache()`	完全透明
适用数据	中间计算结果	热点原始文件
适用场景	单作业内多次复用同一 DataFrame	多作业频繁读取相同 Delta 表

3.2 Delta Cache 的配置（Databricks）

Delta Cache 在 Databricks 上通过节点类型自动启用（选择带有 SSD 的节点类型，如 i3.2xlarge）：

# 查看 Delta Cache 的使用情况（Databricks 专有 API）
spark.conf.get("spark.databricks.io.cache.enabled")  # 是否启用
 
# 手动预热缓存（将热点分区的数据提前加载到 SSD）
from delta.tables import DeltaTable
dt = DeltaTable.forPath(spark, "s3://bucket/delta/orders/")
 
# 读取热点分区（触发缓存填充）
spark.read.format("delta") \
    .load("s3://bucket/delta/orders/") \
    .filter("order_date >= date_sub(current_date(), 7)") \
    .count()
# 后续对这些分区的查询将从 SSD 读取，不走 S3

3.3 开源 Delta Lake 的缓存替代方案

开源 Delta Lake（非 Databricks 平台）没有内置的 Delta Cache，但可以使用以下替代方案：

方案一：Alluxio（分布式内存/SSD 缓存）

Alluxio 在计算层和存储层之间提供透明的分布式缓存，Spark 通过 Alluxio 读取 S3 数据时，热点数据被自动缓存在计算节点的内存或 SSD 中：

Spark → Alluxio（内存/SSD 缓存层） → S3（持久存储）

方案二：Spark 的 CACHE TABLE

-- 将整张表缓存到 Spark 内存（适合小表，不适合 TB 级大表）
CACHE TABLE orders;
 
-- 缓存特定查询结果
CACHE TABLE recent_orders AS 
  SELECT * FROM orders WHERE order_date >= date_sub(current_date(), 7);

第 4 章统计信息维护：CBO 的数据基础

4.1 为什么统计信息对 Delta Lake 很重要

Spark SQL 的 CBO（Cost-Based Optimizer，基于代价的优化器）在制定执行计划时，需要依赖表的统计信息来估计每个操作的数据量，从而选择最优的 Join 策略（Broadcast Hash Join vs Sort Merge Join）和 Join 顺序（多表 Join 时的左右顺序）。

如果统计信息缺失或过期，CBO 只能使用默认假设（如”每张表有 1000 行”），导致：

大表被误选为 Broadcast Join 的广播方（广播一张 100GB 的表 → OOM）
多表 Join 的顺序选择错误（先做笛卡尔积再过滤，而不是先过滤再 Join）
Shuffle 分区数估算错误（导致数据倾斜或资源浪费）

Delta Lake 特有的挑战：Delta Lake 表频繁被写入（Streaming 写入、MERGE 等），每次写入后统计信息就”过期”了。需要定期执行 ANALYZE TABLE 来刷新统计信息。

4.2 ANALYZE TABLE：收集表级别统计

-- 收集表的基本统计（行数、文件数、总大小）
ANALYZE TABLE orders COMPUTE STATISTICS;
 
-- 同时收集所有列的统计（Min/Max/Cardinality/NULL Count）
ANALYZE TABLE orders COMPUTE STATISTICS FOR ALL COLUMNS;
 
-- 只收集关键列的统计（减少计算代价）
ANALYZE TABLE orders COMPUTE STATISTICS FOR COLUMNS 
  customer_id, product_id, amount, order_date;
 
-- 按分区统计（分区表）
ANALYZE TABLE orders PARTITION (order_date='2026-01-15') 
  COMPUTE STATISTICS FOR ALL COLUMNS;

收集后的统计信息存储位置：ANALYZE TABLE 的结果存储在 Hive Metastore（或 Spark Catalog）中，而不是 Delta Log 中——这是 Delta Lake 统计信息体系的一个重要区分：

Delta Log 中的 stats（第 02 篇）：文件级别的 Min/Max，用于数据跳过（Data Skipping），由写入时自动收集
Catalog 中的统计信息：表/列级别的统计（行数、基数、直方图），用于 CBO 查询优化，需要 ANALYZE TABLE 手动收集

4.3 查看统计信息

-- 查看表级别统计
DESCRIBE DETAIL orders;
-- 输出包含：numFiles, sizeInBytes, numRows（如果已 ANALYZE）
 
-- 查看列级别统计（需要先 ANALYZE）
DESCRIBE EXTENDED orders order_date;
-- 输出包含：min, max, distinct_count, null_count
 
-- 通过系统表查看（Spark 3.x）
SELECT * FROM (DESCRIBE EXTENDED orders) 
WHERE col_name = 'Statistics';

4.4 统计信息的过期判断

统计信息在以下情况后会过期（与实际数据不符）：

任何写入操作（INSERT/MERGE/UPDATE/DELETE）后
OPTIMIZE 合并文件后（文件数变少，但统计数据不变）
分区结构变化后

统计信息是否过期的判断：

-- 查看 ANALYZE 的执行时间
SELECT last_analyzed FROM information_schema.tables 
WHERE table_name = 'orders';
 
-- 与最后一次写入时间对比
SELECT MAX(timestamp) AS last_write FROM (DESCRIBE HISTORY orders);
-- 如果 last_write > last_analyzed，统计信息已过期

生产中的统计信息维护策略：

# 定期维护脚本（通过 Airflow/Argo 定时触发）
def refresh_statistics(table_name, days_ago=1):
    """每天维护最近 N 天分区的统计信息"""
    from datetime import datetime, timedelta
    
    end_date = datetime.now().date()
    start_date = end_date - timedelta(days=days_ago)
    
    current_date = start_date
    while current_date <= end_date:
        date_str = current_date.strftime("%Y-%m-%d")
        
        # 只重新分析最近修改的分区
        spark.sql(f"""
            ANALYZE TABLE {table_name} 
            PARTITION (order_date='{date_str}')
            COMPUTE STATISTICS FOR COLUMNS customer_id, product_id, amount
        """)
        current_date += timedelta(days=1)
 
refresh_statistics("orders", days_ago=3)

第 5 章综合性能调优检查清单

5.1 查询慢的诊断流程

Step 1：检查文件数量是否过多
  DESCRIBE DETAIL <table>
  → numFiles > 10000 且平均文件大小 < 100MB？→ 执行 OPTIMIZE

Step 2：检查数据跳过是否有效
  在 Spark UI 的 SQL tab 查看 Scan 节点的 "filesSkipped" vs "filesRead"
  → filesSkipped / (filesSkipped + filesRead) < 50%？
  → 考虑 Z-Order BY 常用查询列

Step 3：检查 Bloom Filter 是否配置
  查询条件包含高基数字符串列（UUID、邮件）？
  → 配置 delta.bloomFilter.columns

Step 4：检查统计信息是否最新
  比较 last_analyzed 和 last_write 时间
  → 统计信息过期 → ANALYZE TABLE

Step 5：检查 Join 策略是否合理
  Spark UI 的 SQL tab，找到 Join 节点
  → 大表 BroadcastHashJoin？→ 可能是 CBO 统计信息错误
  → SortMergeJoin 且一个表很小？→ 可能是统计信息缺失导致未 Broadcast

5.2 写入性能调优

-- 高频小批量写入的推荐配置
ALTER TABLE orders SET TBLPROPERTIES (
    'delta.autoOptimize.optimizeWrite' = 'true',   -- 写入时避免小文件
    'delta.autoOptimize.autoCompact' = 'true',     -- 写入后自动合并小文件
    'delta.targetFileSize' = '268435456',          -- 目标文件大小 256MB（流式场景）
    'delta.dataSkippingNumIndexedCols' = '10'      -- 只收集前 10 列的统计（减少写入开销）
);

5.3 生产环境推荐的完整配置

-- 生产 OLAP 表（低写入频率 + 高查询频率）
ALTER TABLE fact_orders SET TBLPROPERTIES (
    -- 文件管理
    'delta.autoOptimize.optimizeWrite' = 'true',
    'delta.autoOptimize.autoCompact' = 'true',
    'delta.targetFileSize' = '1073741824',    -- 1GB
    -- 数据跳过
    'delta.dataSkippingNumIndexedCols' = '32',
    'delta.bloomFilter.columns' = 'order_uuid,customer_email',
    'delta.bloomFilter.fpp' = '0.01',
    -- 数据保留
    'delta.deletedFileRetentionDuration' = 'interval 30 days',
    'delta.checkpointInterval' = '10',
    -- 事务
    'delta.isolationLevel' = 'WriteSerializable',
    'delta.enableChangeDataFeed' = 'true'
);
 
-- 定期维护（通过 CI/CD 定时作业）
-- 每天 03:00 执行：
--   1. OPTIMIZE ZORDER BY (customer_id, product_id) WHERE order_date = yesterday
--   2. ANALYZE TABLE fact_orders PARTITION (order_date = yesterday) COMPUTE STATISTICS FOR ALL COLUMNS
--   3. VACUUM fact_orders RETAIN 720 HOURS (30天)

小结

Delta Lake 的性能调优是一个系统工程，需要从写入、存储、查询三个维度协同优化：

小文件治理：

Optimize Write：写入时自适应重分区，防止产生小文件（同步，有写入延迟开销）
Auto Compaction：写入后异步合并，修复历史小文件（异步，不阻塞写入）
手动 OPTIMIZE ZORDER BY：定期按分区执行，同时解决小文件和多维查询加速

缓存策略：

Delta Cache（Databricks SSD 缓存）：透明的跨作业持久缓存，热点文件自动缓存到 SSD，无需代码修改
Spark Cache（cache()）：单作业内复用中间计算结果，适合在一个 Spark 作业中多次使用同一 DataFrame
Alluxio（开源替代）：在非 Databricks 环境中提供类似 Delta Cache 的分布式缓存

统计信息维护：

ANALYZE TABLE ... COMPUTE STATISTICS FOR ALL COLUMNS：为 CBO 提供准确的列基数/分布信息
定期刷新（每天对最近更新的分区重新 ANALYZE）；与 OPTIMIZE、VACUUM 组合为日常维护三件套
统计信息存储在 Catalog（非 Delta Log），与文件级别的 Data Skipping 统计是两个独立体系

第 11 篇讲解多引擎生态：Delta Lake 如何与 Presto、Flink、Hive 互操作，Delta 协议的开放性设计，以及 UniForm（Universal Format）如何让一份 Delta 数据同时被 Iceberg/Hudi 协议的引擎读取。

思考题

Delta 的 OPTIMIZE 命令将小文件合并成目标大小的大文件，但会产生写放大。Databricks 的”自动 OPTIMIZE”（Auto Compaction）是如何通过增量合并来减少每次 OPTIMIZE 的代价的？其触发策略与手动 OPTIMIZE 有何不同？

Delta Cache（Databricks 特有，将 S3 数据缓存到本地 SSD）与 Spark 的 .cache()（内存缓存 DataFrame）有本质区别：前者缓存物理文件块，后者缓存逻辑计算结果。在什么查询场景下，Delta Cache 的收益最大？在什么场景下反而浪费了 SSD 空间？

ANALYZE TABLE 收集的统计信息会随着 MERGE/UPDATE 后逐渐过时，导致 CBO 选择错误的 Join 顺序。如何建立统计信息的自动刷新策略，在不过度消耗计算资源的前提下保持准确性？

汀的知识碎片

文章导航

10 性能调优：小文件合并、缓存与统计信息维护

10 性能调优：小文件合并、缓存与统计信息维护

摘要

第 1 章小文件问题：Delta Lake 的慢性病

1.1 小文件是如何产生的

1.2 小文件的危害

1.3 手动 OPTIMIZE：按需合并

第 2 章 Auto Optimize：自动化小文件治理

2.1 为什么需要 Auto Optimize

2.2 Optimize Write：写入时就避免小文件

2.3 Auto Compaction：写入后的自动合并

2.4 Optimize Write vs Auto Compaction 的协同

第 3 章 Delta Cache：透明的列式数据缓存

3.1 Spark Cache vs Delta Cache：两种截然不同的缓存

3.2 Delta Cache 的配置（Databricks）

3.3 开源 Delta Lake 的缓存替代方案

第 4 章统计信息维护：CBO 的数据基础

4.1 为什么统计信息对 Delta Lake 很重要

4.2 ANALYZE TABLE：收集表级别统计

4.3 查看统计信息

4.4 统计信息的过期判断

第 5 章综合性能调优检查清单

5.1 查询慢的诊断流程

5.2 写入性能调优

5.3 生产环境推荐的完整配置

小结

参考资料

On this page

汀的知识碎片

文章导航

10 性能调优：小文件合并、缓存与统计信息维护

10 性能调优：小文件合并、缓存与统计信息维护

摘要

第 1 章 小文件问题：Delta Lake 的慢性病

1.1 小文件是如何产生的

1.2 小文件的危害

1.3 手动 OPTIMIZE：按需合并

第 2 章 Auto Optimize：自动化小文件治理

2.1 为什么需要 Auto Optimize

2.2 Optimize Write：写入时就避免小文件

2.3 Auto Compaction：写入后的自动合并

2.4 Optimize Write vs Auto Compaction 的协同

第 3 章 Delta Cache：透明的列式数据缓存

3.1 Spark Cache vs Delta Cache：两种截然不同的缓存

3.2 Delta Cache 的配置（Databricks）

3.3 开源 Delta Lake 的缓存替代方案

第 4 章 统计信息维护：CBO 的数据基础

4.1 为什么统计信息对 Delta Lake 很重要

4.2 ANALYZE TABLE：收集表级别统计

4.3 查看统计信息

4.4 统计信息的过期判断

第 5 章 综合性能调优检查清单

5.1 查询慢的诊断流程

5.2 写入性能调优

5.3 生产环境推荐的完整配置

小结

参考资料

On this page

第 1 章小文件问题：Delta Lake 的慢性病

第 4 章统计信息维护：CBO 的数据基础

第 5 章综合性能调优检查清单