DBA性能调优内功心法（七）：固化篇——SQL Profile与SPM，将最优计划定为“心诀”

阅读时间： 2025年08月03日
章节： 2.6 如何稳定执行计划
摘要： 本章节直面SQL优化中最棘手的问题之一：执行计划的非预期变更。它详细介绍了Oracle为解决此问题提供的两大“定海神针”——SQL Profile和SQL计划管理。理解这两种技术的机制、差异和适用场景，对于保障核心业务SQL的性能持续稳定至关重要。

一、核心概要

在理想世界中，优化器总能为我们的SQL选择最优计划。但在现实中，统计信息变化、数据库版本升级、参数变更等因素，都可能导致优化器“变卦”，选择一个性能更差的执行计划，引发生产问题。本章节的核心，就是教会我们如何应对这种“性能衰退”，将优质的执行计划“固定”下来。

• • SQL Profile：它是一种“引导式”的稳定技术，通过为特定SQL附加一套“校正信息”，来引导优化器做出我们期望的选择。
• • SQL计划管理（SPM）：它是一种“白名单式”的稳定技术，通过建立一个“可接受计划”的基线库，来阻止优化器使用未经认可的新计划。

二、关键概念重述与实战解读

1. 1. 使用SQL Profile来稳定执行计划

• • 是什么：SQL Profile并非强制锁定一个执行计划，而是为某条SQL语句创建的一组辅助统计信息。当优化器再次解析该SQL时，会结合这些“额外情报”进行成本计算，从而大概率地重现我们期望的那个优秀执行计划。
• • 核心思想：与其说是“稳定”，不如说是“校正”。它告诉优化器：“你之前对这条SQL的成本估算可能不准，参考一下我给你的这些修正系数，你再算算看？”
• • DBA视角：
• • Automatic类型：这是由Oracle的自动SQL优化任务（Automatic SQL Tuning Advisor）创建的。当系统自动发现有性能严重衰退的SQL时，可能会自动为其创建一个Profile来修复。作为DBA，我们需要知晓并监控这些自动生成的Profile。
• • Manual类型：这是我们DBA手动创建的，控制力更强。通常，我们通过SQL优化指导工具（SQL Tuning Advisor）分析SQL后，接受其建议来生成，或者使用DBMS_SQLTUNE包来手动加载。
• • 适用场景：对于那些因统计信息陈旧或数据倾斜，导致优化器基数估算严重失准的复杂SQL，SQL Profile是极佳的“外科手术式”解决方案。它的优点是灵活，当数据发生变化，只要原计划在Profile的“引导”下依然是成本最优，计划就不会改变。但如果未来出现了成本更优的新计划，它也可能随之演进。

• • 是什么：SQL计划管理（SQL Plan Management, SPM）是一种更严格、更具前瞻性的计划稳定机制。它为SQL语句创建一个“计划基线”，这个基线中存放了一个或多个“已认可”的执行计划。
• • 核心思想：这是一种“审批”机制。优化器可以自由产生新计划，但没有经过DBA“盖章认可”的计划，就不允许在生产中使用。
• • 工作流程：

1. 1. 为SQL创建计划基线，将当前的好计划作为第一个“已认可”计划。
2. 2. 当SQL再次执行时，优化器产生一个新计划。
3. 3. 优化器检查新计划是否存在于基线中且已被认可。
4. 4. 如果存在，则使用之。如果不存在，优化器会放弃这个新计划，转而使用基线中一个已被认可的、成本最低的旧计划。同时，这个未经审批的新计划会被记录下来，等待DBA的“裁决”。

• • SPM是防止性能衰退的“金钟罩”，是系统升级、数据迁移等重大变更期间的定心丸。它提供了极高的可预见性，确保了SQL行为不会发生意外改变。
• • 它的挑战在于管理。DBA需要定期“演进”计划基线，即对那些被记录下来的新计划进行评估，如果发现新计划确实更优，就需要手动将其状态更改为“已认可”，否则系统的性能将无法得到提升，被“锁定”在旧的计划上。

总结对比

• • SQL Profile是“循循善诱的导师”：它不强制你，而是给你提供额外信息，帮助你（优化器）自己想明白，做出正确的选择。
• • SPM是“严格的门卫”：它不管你怎么想，只认“通行证”（已认可的计划），没有通行证一律不放行。

在实践中，两者可以结合使用。但通常，对于追求极致稳定性的核心系统，尤其是在版本升级等场景下，SPM是更可靠、更具防御性的选择。而对于单个的、因CBO估算不准导致的疑难杂症，SQL Profile则提供了更灵活、更精确的解决方案。