自适应查询优化（Adaptive Query Optimization, AQO） 是数据库系统中一种动态调整查询执行计划的技术，旨在根据运行时的统计信息和实际执行反馈对查询计划进行调整，从而获得更高的性能。传统的查询优化器通常基于查询前的静态信息来生成执行计划，而 AQO 则引入了运行时的动态反馈机制，以应对不确定性和数据分布的变化。
1. 自适应查询优化的背景
传统的查询优化器主要依赖于代价模型（Cost-Based Optimizer, CBO），通过静态的代价估计（如表的大小、索引使用情况、行数等）来生成最优的查询计划。然而，现实中存在许多无法预知或估计不准确的情况，例如：
- 数据分布的偏斜：统计信息可能无法精确反映某些列中值的分布，导致不准确的选择性估计。
- 索引或统计信息过期：当数据库的内容频繁更新时，之前收集的统计信息可能变得不准确，影响查询优化器的决策。
- 复杂联接操作的选择性估计错误：多表联接的代价估计可能不够精确，特别是在涉及多个过滤条件时。
为了解决这些问题，自适应查询优化应运而生。AQO 不仅依赖预先收集的统计信息，还会在查询执行过程中动态调整执行计划，以应对数据和查询行为的变化。
2. 自适应查询优化的核心思想
自适应查询优化的核心思想是：通过运行时反馈机制动态调整查询计划。AQO 可以在查询执行期间或执行之后，利用实际数据反馈来修正查询计划。
2.1 执行前调整
执行前的调整是基于查询计划生成后的预估信息来决定是否需要自适应处理。数据库系统会在执行前检查某些关键因素，如：
- 统计信息是否充分。
- 预计的代价和查询实际代价的差异是否有风险。
如果系统检测到潜在的风险，如统计信息不足或某些选择性估计有误差，那么可能会在查询开始前执行一个初步的探测操作，称为**"进度调整"**（Progressive Refinement）。比如，先从部分数据中抽样，以获取更精确的选择性估计。
2.2 执行时调整
运行时自适应调整 是 AQO 的核心。它允许查询执行器根据中间结果和实际执行情况调整查询计划。例如：
-
自适应表联接策略：原本优化器可能选择使用哈希联接（Hash Join），但在实际执行中发现，哈希表的构建代价过高或某一侧的表大小远小于预期。这时，AQO 可以动态切换到嵌套循环联接（Nested Loop Join）或合并联接（Merge Join）。
-
自适应排序与缓冲管理：在执行排序操作时，原本估计排序的输入可以全部放入内存，但运行时发现数据量超出内存容量。此时，查询优化器会动态调整为外部排序（External Sort），避免内存溢出。
2.3 执行后反馈与学习
执行后，AQO 会将运行时收集的实际代价、选择性等反馈信息用于后续的查询优化。它会更新数据库的统计信息或直接存储在优化器的自适应规则中，以便未来的查询优化更为精确。
-
自适应代价模型更新：基于查询的实际执行情况，优化器会更新代价估计模型。特别是在多次执行同类查询时，优化器会调整参数（如 CPU、IO 等成本模型），从而生成更精确的查询计划。
-
自适应学习：某些数据库系统会采用机器学习技术，分析历史查询执行数据，从中学习查询计划生成和执行的最佳策略。这种方法可以在面对类似查询时提供更准确的优化方案。
3. 自适应查询优化的技术实现
自适应查询优化的实现依赖于一些关键技术，包括执行反馈机制 、统计信息收集机制 和动态计划切换。下面详细分析这些技术。
3.1 执行反馈机制
执行反馈机制是 AQO 的基础。在查询执行过程中，数据库会收集大量的执行信息，这些信息包括：
- 中间结果的行数：优化器会在每个操作（如过滤、联接、聚合）之后，统计中间结果集的行数。
- 实际 IO 代价：包括读取磁盘块的数量、缓存命中率等。
- 执行时间：每个操作的实际执行时间与优化器预估时间的比较。
这些信息会作为反馈数据存储，供后续查询计划调整使用。例如，如果过滤操作的选择性与预估的差距很大，优化器会在后续查询中修正选择性估计，或者直接调整过滤条件的执行顺序。
3.2 自适应的统计信息收集
自适应查询优化的一个重要方面是对统计信息的动态收集。许多数据库系统会在查询过程中收集额外的统计信息，特别是在现有统计信息不足的情况下。
-
动态采样：如果发现某些列的选择性估计误差较大，系统可能会启动动态采样机制，即对部分数据进行快速采样，生成更精确的选择性估计。
-
实时统计更新：在查询执行过程中，数据库系统会动态更新某些列或索引的统计信息，尤其是在数据频繁变化的场景下，这样可以确保下次查询能够利用更新后的统计数据。
3.3 动态计划切换
动态计划切换是自适应查询优化中的一个重要机制。当查询执行器发现当前执行计划不再适合实际情况时，可以在运行时切换到另一种执行计划。
例如，在 SQL 查询的初始阶段，优化器可能会选择哈希联接，但在扫描一部分数据后，发现哈希表的构建过于缓慢，或者表的大小远小于预期。在这种情况下，系统可以在不终止查询的前提下，切换到嵌套循环联接，从而减少总体执行时间。
动态计划切换的挑战：
- 状态迁移：在计划切换时，系统必须确保中间结果和上下文能够无缝迁移到新的执行计划中。这可能需要保存部分数据的快照，并确保上下文切换不会带来一致性问题。
- 成本评估：计划切换本身会带来一定的开销，系统需要在开销和潜在收益之间做出权衡，确保切换是有利的。
4. 自适应查询优化的应用场景
自适应查询优化在以下几类场景中最为常见和有效：
4.1 数据分布高度不均匀
当数据分布不均匀时，传统优化器可能难以准确估计某些查询操作的选择性。例如，某列的某些值可能占据大量记录，而其他值的记录很少。这种情况下，AQO 可以根据运行时的反馈动态调整计划，避免代价估计偏差带来的性能问题。
4.2 高度动态的数据环境
在一些 OLTP 系统中，数据变化频繁，统计信息可能迅速过时，导致优化器的代价模型不准确。自适应查询优化可以根据查询的实际执行反馈更新代价模型，确保计划适应最新的数据分布。
4.3 复杂联接查询
多表联接查询中，选择性估计误差的累积可能导致严重的代价偏差，尤其是在多重过滤条件或大表联接时。AQO 可以在执行过程中实时调整联接策略或过滤顺序，显著提升执行效率。
5. 自适应查询优化的典型实现
5.1 Oracle 自适应查询优化
Oracle 数据库从 12c 版本开始引入了自适应查询优化（Adaptive Query Optimization），其中包含两个核心组件：
- 自适应计划（Adaptive Plans）：允许在运行时调整联接方法和访问路径。例如，如果发现哈希联接不如嵌套循环联接高效，Oracle 可以动态切换。
- 自适应统计（Adaptive Statistics）：Oracle 允许在执行过程中收集动态统计信息，并在查询优化过程中使用这些信息生成更好的计划。
5.2 PostgreSQL
PostgreSQL 在查询优化中也逐步引入了自适应元素。例如，PostgreSQL 的自适应优化策略可以在查询执行时动态调整并行执行的线程数量，或者根据某些情况下的统计信息，调整查询的执行策略。
5.3 Microsoft SQL Server
SQL Server 的自适应查询处理（Adaptive Query Processing）包含多个机制：
- **自
适应联接（Adaptive Join）**：SQL Server 可以在运行时动态切换联接策略（如哈希联接和嵌套循环联接）。
- 批处理模式自适应内存授予（Batch Mode Memory Grant Feedback）：在批处理模式下，SQL Server 会根据实际内存使用情况调整内存授予。
6. 自适应查询优化的挑战
尽管自适应查询优化在提升性能方面有显著效果，但它也面临一些挑战：
- 计划切换的开销：动态调整计划可能会引入额外的开销，如上下文切换和状态保存，如何在不显著影响性能的前提下进行自适应调整是一个难题。
- 反馈数据的处理：如何高效地处理运行时收集的大量反馈数据，并在合理的时间内调整查询计划是 AQO 系统设计的一个关键问题。
- 一致性保障：在动态调整执行计划时，确保中间结果的一致性和查询正确性至关重要。
总结
自适应查询优化 通过动态调整查询计划来应对不确定性和统计信息不准确的问题，显著提高了数据库系统的查询性能。其核心技术包括执行反馈、动态计划切换、以及自适应统计信息的收集与更新。虽然实现复杂，但在数据分布不均、查询复杂、数据动态变化等场景下，自适应查询优化能极大提升数据库的整体效率。
产品简介
- 梧桐数据库（WuTongDB）是基于 Apache HAWQ 打造的一款分布式 OLAP 数据库。产品通过存算分离架构提供高可用、高可靠、高扩展能力，实现了向量化计算引擎提供极速数据分析能力，通过多异构存储关联查询实现湖仓融合能力，可以帮助企业用户轻松构建核心数仓和湖仓一体数据平台。
- 2023年6月，梧桐数据库（WuTongDB）产品通过信通院可信数据库分布式分析型数据库基础能力测评，在基础能力、运维能力、兼容性、安全性、高可用、高扩展方面获得认可。
点击访问：
梧桐数据库（WuTongDB）相关文章
梧桐数据库（WuTongDB）产品宣传材料
梧桐数据库（WuTongDB）百科