《Self-tuning Database Systems: A Systematic Literature Review of Automatic Database Schema Design and Tuning》

探索 SQL 和 NoSQL 数据库自动化模式调优方法的实质性工作，也是首个提出用于评估和比较不同模式调优解决方案的分类体系的工作。本综述有助于探讨当前解决方案的动机与能力之间的差距，并据此确定未来的研究方向。通俗点来讲就是探究数据库内部数据结构设计的自动化方法，使其跑得更快，效果更好。

关系型数据库自动化模式设计

关系型数据库的自动化模式设计主要侧重于物理模型设计。

物理结构设计包括：

  • 辅助加速对象：索引、物化视图
  • 底层数据组织对象：在多维关系型数据库中使用的聚簇键，在无共享并行数据库系统中使用的分区键。

自动化物理设计通常三步走：

  1. 生成可能的备选方案
  2. 评估备选方案
  3. 选择代价最低的最佳方案

基于上述流程，研究人员将自动化物理设计拆解为两个最核心的技术维度：

  • 代价模型 (Cost Model)：它是系统的“评估裁判” 。主要负责评估所有备选设计，并估算出每种设计在跑完整的工作负载时的总代价是多少。
  • 搜索策略 (Search Strategy)：它是系统的“寻宝猎人” 。由于可能的组合方式成千上万，它的任务是使用高效的算法，在茫茫多的物理配置中，找到总代价最低的那个最优解。

cost model

独立代价模型

在数据库系统外部构建的代价模型

  • 概率模型：早期的学者（如 Stonebraker 和 Schkolnick）尝试基于事务的统计属性（比如某个列在查询中出现的概率）来算账。
  • 预测与经验：有些人使用指数平滑技术来进行预测 ，或者把人类专家的经验写成基于规则的专家系统。
  • 公式推算：采用简单的线性成本模型估算查询涉及的行数，或者使用分析成本模型预测数据相关性对索引查找的影响。此外，还有基于 I/O 的模型，通过计算页面/块的访问次数，或者综合计算 I/O 和 CPU 操作的加权总和来衡量成本。

基于外部代价模型的方法存在严重的缺陷。它们无法保证所建议的存储方案能被优化器充分利用。此外，每当优化器发生变化时，相关工具就会过时。

优化器代价模型

直接借用查询优化器自带的成本模型，生成的物理方案基于从优化器中提取的信息，因此能够被优化器充分利用。此外，如果优化器随时间演进，这些方案也能保持同步
但是，对于包含多列的海量数据库，通过传统的全表扫描技术创建统计信息是不可行的。

微软在 1997 年的 Auto-admin 项目中首创了将“what-if”接口扩展到优化器的做法 。
它的巧妙之处在于：不需要真刀真枪地去硬盘上建索引（物化），而是通过向系统目录中注入虚假的元数据和统计信息，在优化器内部“模拟”这些物理结构 。这种神仙操作后来被许多商业数据库采纳（比如 PostgreSQL 里的 HypoPG 插件）。

面对庞大的数据库，备选方案太多，导致系统要频繁调用这个“what-if”接口，这会带来极其高昂的计算成本。
对此，后来的研究提出了快速的“what-if”优化技术以减少调用次数，或者将优化器方法与知识库方法结合起来使用。

学习型代价模型

虽然调用原生优化器很精准，但频繁调用的开销依然太大，而且一旦优化器对数据基数（Cardinality）估计错误，就会导致系统完美错过真正好的配置。为了打破这个瓶颈，学术界迎来了最新的进化方向：用机器学习来预估成本。

不再依赖预先写死的成本公式，而是利用深度神经网络（DNN）和强化学习（RL）等机器学习技术来估算成本 。
整个策略的核心目标是：在完全不需要先验成本模型知识的情况下进行调优，整个成本模型是靠 AI “学习”出来的。

像 Oracle 这种云端自治数据库，就是通过在现有的数据库系统中引入机器学习代理（ML agents）来实现的。
更有一些研究（如 NoisePage 项目）干脆另起炉灶，试图创建全新的数据库架构，彻底依靠各种 ML 算法来预测部署某些配置能带来多少收益和成本。

search strategy

精确方法

通过考虑所有可能的设计选择来确定一组最优物理结构。
问题：

  1. 必须进行大幅度简化；
  2. 如果查询处理策略或数据库管理系统（DBMS）的其他建模方面发生变化，模型就会失效。

近似方法

  1. 传统启发式与算法流派 (Heuristic & Algorithmic Solutions)

这是最广泛使用的一类方法，核心思想是“基于经验法则”来大幅度修剪搜索空间，砍掉那些明显不靠谱的方案 。

  • 贪心算法 (Greedy approaches) ：就像吃自助餐，每次都挑眼前最贵的拿。系统会在每一步都选择当前看来能最大程度降低成本的物理结构（比如先建一个收益最高的索引，再建第二高的），直到受到内存或磁盘空间的限制。
  • 进化/遗传算法 (Evolutionary/Genetic algorithms) ：模拟大自然的优胜劣汰。系统先随机生成几套调优方案，把表现好的方案“交配”（组合它们优秀的索引），并引入一些“突变”，一代代繁衍出更优的配置。
  • 分支定界 (Branch-and-bound) 与松弛法 (Relaxation-based) ：这类算法通过设定上下限，在搜索树中果断砍掉那些哪怕发挥到极致也不如当前已知方案的“树枝”，从而极大地加快搜索速度。
  1. 数学与组合优化流派 (Combinatorial Optimization)

当问题变得复杂，比如不仅要考虑查询变快，还要考虑硬盘装不装得下时，研究人员就会请出数学模型：

  • 背包问题 (Knapsack Problem) 模型 ：这是一个非常经典的隐喻。假设你的数据库内存（背包容量）只有 10GB，而备选的索引和视图（物品）加起来有 50GB。每个索引都有自己的“体积”（占用空间）和“价值”（为查询省下的时间）。系统会使用多项式时间近似算法，或者变体的背包算法搭配随机交换机制，来计算怎么往这 10GB 内存里塞索引，能让整体的提速价值最大化 。
  • 整数线性规划 (ILP) ：有些研究会把物理设计转化为严谨的 ILP 数学公式，然后丢给专业的商业数学求解器（比如利用拉格朗日松弛或列生成技术）去算出一个非常接近最优解的答案，并给出一个明确的误差范围。
  1. 前沿流派：基于学习的方法 (Learning-based Approaches)

传统的近似算法有一个通病：它们都是“一锤子买卖”， 缺乏学习机制 ，不知道去反思自己刚刚推荐的方案到底好不好。为了解决这个问题，研究人员引入了最前沿的 AI 技术：

  • 强化学习与深度强化学习 (RL & DRL) ：这就像训练一只小狗。系统把调优过程建模为“马尔可夫决策过程 (MDP)”。AI 代理在数据库里尝试添加或删除某个索引（做出动作），如果查询变快了，就给它一个“奖励”；如果变慢了，就给个“惩罚”。
  • 举一反三的能力 ：通过不断地试错和深度强化学习，AI 能够自己总结出在特定工作负载下（无论是 OLAP 还是 OLTP），挑选索引或物化视图的最佳策略。

物理数据库设计方法概述

前 AutoAdmin 时代

物理设计问题早在 70 年代初就被提出来了，最开始大家只盯着“怎么给文件选最优的索引”这一个问题。
早期的科学家们试图用基于概率的精确分析模型来求出“完美”的索引集合。但尴尬的是，穷举所有组合的计算量太大了，这种方法根本没法在现实中用。
后来大家妥协了，开始寻找“近似解”，并且把研究范围扩大到了有限的物理结构上，比如索引、数据分区、多维聚簇，以及专门针对数据仓库（OLAP）的物化视图 。
这个时代最大的特点是——所有的研究都停留在学术论文里，没有任何人开发出能直接用在商业数据库里的物理设计工具

AutoAdmin 开启的工业化革命

1996年，微软研究院启动了鼎鼎大名的 AutoAdmin 项目，目标就是让关系型数据库学会“自我调优” 。
1998 年，随 SQL Server 7.0 发布了第一个物理设计工具——索引调优向导 (Index Tuning Wizard, ITW) 。它的杀手锏就是我们在上一节聊过的“扩展了查询优化器以支持 what-if（假设）接口” 。
到了 SQL Server 2005，ITW 升级成了功能完备的“数据库引擎调优顾问 (DTA)” 。DTA 非常强大，它能综合推荐索引、索引视图甚至水平范围分区。
为了应对大型数据库，它还使用了工作负载压缩等技术。
早期工具的问题是，它们不知道什么时候该启动，必须靠 DBA 凭直觉去点运行。因此，微软后来开发了 Alerter（轻量级警报器，告诉你什么时候该调优了）和在线索引选择工具（持续监控并随时修改设计），迈出了走向真正的“自动化”的重要一步。

AutoAdmin 之后至今

在这段时期，物理架构调优被明确划分为了三种模式：手动/离线 (Manual)、半自动 (Semi-automatic) 和 全自动/在线 (Full-automatic)。

  1. 各大商业巨头跟进的“手动/离线模式”有了微软的带头，其他巨头迅速跟进：

    IBM：推出了 DB2 Design Advisor，能把索引、物化视图、分区和多维聚簇 (MDC) 放在一起综合推荐 。其底层用到了背包算法、遗传算法等高级技巧。

    Oracle：在 10g 版本推出了 SQL Access Advisor，随后在 11g 中也加入了分区推荐功能。

  2. 走向未来的“全自动/在线模式”学术界觉得离线工具还需要人点鼠标，不够酷，于是研究重点转向了完全不需要人工干预的在线技术：

    数据库破解 (Database Cracking)：这是一个极其聪明的想法。它把每次查询不单单看作是取数据，而是看作一次“顺手整理数据库”的建议。一边查询，系统一边在后台把数据“破解”成更小的块，渐渐地索引就自己建立起来了。

    持续监控与调优系统：像 QUIET、COLT 这样的框架，它们在后台默默盯着工作负载的变化，收集统计信息，一旦发现性能下降，立刻在线自动调整物理设计。

  3. AI 时代：自动驾驶数据库 (Self-driving RDBMS)这是目前最前沿的方向，把机器学习 (ML) 和强化学习 (RL) 塞进了数据库引擎里。

    宏观统筹：这些系统（如 Peloton/NoisePage）不再局限于某一个功能，而是预测未来的工作负载，把物理设计、参数配置、硬件资源一把抓，实现真正的“无人驾驶”。

    开源与商业落地：像开源的 openGauss 数据库集成了各种“学习型优化器”，而商业界也有了 Oracle 自治数据库 (Autonomous database)、阿里云自研数据库，以及微软 Azure 中全自动化的索引服务。

nosql自动化模式设计

nosql的分类

  • 键值存储 (Key-Value)：最简单的架构，像字典一样通过唯一的“键”来找“值”。
  • 文档存储 (Document)：键值对的升级版，值变成了半结构化的文档（如 JSON），极其灵活，每条文档的结构甚至可以完全不一样。
  • 宽列存储 (Wide-Column)：数据存在“列族”里，不同行可以有完全不同的列，随时可以动态添加。
  • 图数据库 (Graph)：基于节点（实体）和边（关系）的结构，专门处理复杂的关系网。

模型层级 (Level of Data Model)：
分为单模型 (Single-model) 和 多模型 (Multi-model) 。
现在的趋势是“多存储系统（Polystores）”，也就是一个大系统里同时混用好几种不同类型的数据库。这就需要设计一个全局统一的虚拟骨架（ metamodels，如 NoAM, U-Schema）来整合它们 。

为 NoSQL 发明了三种截然不同的设计套路

第一派：正向工程 (Forward Engineering / Schema-first)

—— “先画图纸，再盖大楼”
这种方法是从传统的概念图（比如 UML 或 ER 图）或者现成的关系型数据库出发，通过一套规则把它们“翻译”成 NoSQL 的数据模型。它又分为两个子流派：

  • 工作负载无关 (Workload-agnostic) ：也就是“闭门造车派”。它们只关心怎么制定转换规则（比如把关系表的某行变成 JSON 文档），完全不管数据库以后要跑什么查询。
  • 工作负载驱动 (Workload-driven) ：也就是“量体裁衣派”。它们会先分析程序会跑哪些查询（读多还是写多），然后通过 反范式化（denormalization，也就是故意制造数据冗余） 来优化查询性能。比如著名的 CONST 系统，就是目前唯一一个能在线监控宽列存储工作负载并自动修改架构的闭环系统 。

第二派：逆向工程 (Reverse Engineering)

—— “从废墟中还原建筑图纸”

NoSQL 最大的特点是“无模式”，写数据时随心所欲，但这会导致后期根本不知道库里到底存了啥格式的数据。

  • 为了方便开发人员写查询语句、理解和可视化数据，科学家们研发了逆向工程 。
  • 它的核心工作就是直接去扫描数据库里现存的海量 JSON 散乱数据，然后用算法硬生生地总结（推断）出一套逻辑或物理层面的结构图（Schema）出来 。

第三派：往返工程 (Roundtrip Engineering)

—— “图纸与大楼实时同步”
这是最高级的形态，也是目前研究最少的一块 。

  • 它结合了正向和逆向工程。因为在现代开发中，代码和模型是相互关联的 。
  • 它的目标是实现双向转换：如果你在概念图上修改了骨架，底层数据库会自动跟着变；反过来，如果你在底层数据库里加了新字段，上层的概念图纸也能瞬间自我更新 。

衡量数据库模式设计方法

工作负载类型

数据库在干活时，主要面临三种情况：

  • 事务型 (OLTP)：比如电商双十一，疯狂地小批量插入和修改订单 。
  • 分析型 (OLAP)：比如年底算总账，进行极其复杂的历史数据大盘点 。
  • 混合型 (Hybrid)：既要快速接单，又要实时出报表 。
    对比：SQL 数据库已经有能够同时搞定混合工作负载 (Hybrid) 的物理调优方案了 。但是，NoSQL 领域目前还没有任何支持混合工作负载的模式设计方案，主要原因是 NoSQL 在处理事务和分析时，逻辑模式的差异实在太大了 。

调优方式

  1. 静态/离线调优 (Static/Offline)：系统像个没主见的助理，算出一套方案后提交给数据库管理员 (DBA)，问“老板，您看这个行吗？” 。
    缺点：极度依赖人工，且只适用于工作负载稳定不变的场景 。大多数 SQL 和 NoSQL 的研究目前都还停留在这一步 。
  2. 动态/在线调优 (Dynamic/Online)：系统是个成熟的管家，自己盯着数据流，发现不对劲就全自动调整架构，不需要人工干预 。SQL 领域已经有很多这种在线方案（比如前文提到的数据库破解技术）。而 NoSQL 领域目前仅仅只有 CONST 这一个系统能做到 。
  3. 被动 (Reactive) vs. 主动 (Proactive)：
    被动：出了问题、查询变慢了再去改结构 。
    主动：能够预测未来几个小时会发生什么，提前把索引和分区建好 。目前只有 SQL 数据库有主动式的研究，NoSQL 领域的主动式调优完全是一片空白 。
  4. 内部 (Internal) vs. 外部 (External)：调优模块是硬编码塞进数据库引擎内部（难维护，但不易受干扰），还是作为一个独立的外部管家（容易移植复用给其他数据库）。

未来的四大黄金研究方向

  • NoSQL 的完全自治在线调优：填补目前的巨大空白，让 NoSQL 也能全自动实现在线架构调整 。
  • 控制在线调优的“副作用”：在线调优会消耗系统资源（开销）。未来的系统需要更聪明，不仅要能预测改版的好处，还要防止系统因为一时的流量波动而产生过度反应（频繁瞎折腾）。
  • 开发主动式（预测型）方法：运用机器学习，精准预测变化发生的时间点，让调优走在问题发生之前（尤其是针对 NoSQL）。
  • 多模型数据库的统一设计：未来的数据库将是“缝合怪”（一个大系统里兼顾关系表、文档、图等多种模型）。为这种“多模型数据库”设计一套通用的、全局的自动架构方法，是下一个风口.