SQL，作为与数据库交互的主要方式，其管理能力对数据库的安全稳定运行至关重要。作为数据库的标杆性产品，Oracle 在这方面能力非常全面；与之相对的是国产数据库还存在一定的差距。当前很多企业正面临国产化替代的过程，更需正视这一差距，通过在生态工具、实施方案及自研增强等多种手段加以完善补充。下文从Oracle能力为基础，介绍相关能力作用及国产数据库当前现状。文中选择了部分国内主流数据库产品及开源产品作为对比，其相关能力取自官网和部分朋友的反馈。对比中加入了开源数据库，主要是因为部分国产数据库是基于开源数据库二次化开发而来，此处列入方便对比。这里特别感谢几位的朋友大力支持。
1. SQL 管理能力大对比
在下文展开之前，我们先通过一张表格做个全局性的概览。
图片
1).SQL 解析
SQL 解析，简单描述就是将用户提交的 SQL 语句，交由数据库内核，经多个步骤后生成最终的执行计划，并交由执行器来完成执行。这其中关键能力有两个，一是执行计划缓存，一是解析过程的跟踪。
❖ 计划缓存
执行计划的缓存可以加速后续相同语句的执行速度，大部分数据库都内置了缓存能力，当然有利就有弊，有了缓存能力就需考虑缓存的更新机制等问题。Oracle Shard Pool 中的 Library Cache，保存了SQL对应的多个执行计划（以游标的形式存在）。可以说 Oracle 对执行计划的存储控制，是我见过最为完善的，考虑到很多情况（如绑定变量、数据特征等等）。国产数据库大多也支持了执行计划缓存，但管理粒度比较粗放且很多细节是未知的，相关文档资料较少。
❖ 过程跟踪
解析过程的跟踪，作为 SQL 优化的基础，理解执行计划的生成过程非常重要；数据库自身是否提供了一个窗口可以去观察内部执行机理，对于 DBA 优化非常实用。优化器生成执行的计划的过程是比较复杂的，当一条语句的执行计划较差，一个很好的入口就是查看下优化器生成执行计划的过程。Oracle 提供了等待事件10053，可以对整个执行过程做了详细的了解，通过对这个事件的阅读可以帮我们回答很多问题。例如为什么选择这个索引？多个近似成本的执行计划的选择？等等。国产数据库在这方面功能差距较大，大多没有提供这一能力，很多时候是要靠 DBA 的经验来评估判断的。
图片
2).执行计划
执行计划，可以语句在数据库中的执行路径，是了解数据库运行机理的重要窗口。在此部分需提供的能力包含几个，分别是执行计划的查看、固定、迁移和销毁。
❖ 查看执行计划
可以说优化SQL的第一步就是获得一份准确详实的执行计划。这里要区分两种情况，一种是根据用户提交的语句生成的执行计划，一种是对执行过或进行中的语句获得其执行计划。前者是优化器新生成的执行计划，但不代表是真实执行的，两者可能会存在差异。Oracle提供了多种手段查看执行计划，而且可查询当前正在执行的或已结束语句的执行计划。国产数据库也都提供了查看执行计划的手段，但一般仅支持第一种方式且信息输出粒度也较Oracle存在一定差距。
❖ 固定执行计划
令DBA一个非常头疼的问题就是执行计划不稳定，受多种因素影响会出现这一现象，对于前端业务来说就会出现忽慢忽快的问题。为了使SQL语句的执行稳定下来，可以考虑对一些关键语句进行固定执行计划的工作。Oracle提供了多种手段达到这一目的。一种是常见的Hint方式，这种方式比较直接，但会导致失去其他优化的可能性的同时，需要手工修改语句；另外Oracle还提供了其他多种手段，从9i的Stored Outline、10g的SQL Profile到11g的SQL Plan Management，实现从被动到主动、从固定到灵活地实现了执行计划的稳定性。这方面国产数据库也都提供了一定的能力，但相对来说能力较少，还处于被动补救的状态，尚不支持主动防御性的能力。
❖ 迁移执行计划
当数据库需要迁移时，除了数据本身迁移外，还有很重要的一部分就是执行计划的迁移，这对于在新环境的稳定运行很关键。Oracle提供了多种方式完成迁移过程，国产数据库这方面比较缺失。
❖ 清理执行计划
如果一条语句的某个执行计划异常，常见的一个方式是让其失效后，由优化器重新生成一份执行计划。这时就需要能精准销毁到指定执行计划的能力。Oracle是提供了专有的命令来完成清理，当然也可以通过权限变更等手段间接来清理掉执行计划。国产数据库部分具备精确清理的能力，部分尚不具备。
图片
3).SQL 优化
❖ 诊断优化
当出现某条语句性能比较差的情况，固然可以通过DBA人工来完成优化，但更优的方式是系统内置的诊断优化的能力。以Oracle为例，就提供了一组这样的能力，它通过对数据对象、统计信息、SQL语句本身等多维度评估，给出优化建议，用户更可以基于优化建议一键完成优化动作。这边可大大提高优化效率、降低优化成本，减轻DBA的工作压力。这方面国产数据库也具备一定能力，但一般都是通过外置工具来完成。
❖ 自动优化
上面谈到的优化动作是指人为主动干预，诊断优化指定语句，数据库还可以提供自动优化能力。Oracle一方面通过将若干上述能力组合实现了批量自动优化；一方面还提供一种自适应特性，即在语句执行过程中，动态根据执行情况实时干预后面的执行逻辑，修正执行计划达到最优。部分国产数据库也具备了类似的能力，但具体还待验证。
图片
4).执行过程
❖ 查看过程
对SQL执行过程的全方位追踪，也非常重要，可以真实了解语句的执行状态，根据执行过程中暴露出的问题有针对性的进行调整优化。要做到对语句执行追踪是比较难的，需要兼顾效率、开销、粒度等。Oracle在这方面做的非常突出，其提出的事件模型较好地解决了这一问题。其提供了丰富的手段可以对正在执行或已经执行结束的语句实现过程查看。国产数据库在这方面差距还是很明显的，也看到有国内产品在仿照Oracle的方式来实现这一能力。
❖ 慢SQL
慢SQL，是DBA优化的入手点，这里谈到的慢SQL狭义上指执行时长超过预期的SQL，广义上是对更多资源粒度使用超出预期语句的集合。这方面Oracle基于AWR的存储库，提供了丰富的维度去检索查询语句。国产数据库这方面做到稍显单薄些，大多仅有对运行时间超长语句的输出。
图片
5).其他能力
除了上述能力外，还有些能力也有助于对SQL的管理。例如可以重点标识语句的“着色”功能，用于升序迁移评估的SQL回放功能，用于调整对象进而影响执行计划的不可见索引，用于应急处理语句的雨具重写功能等。这部分功能比较零散，大多根据实践中不断增强，各厂商差异较大。
图片
2. 国产数据库实施建议
针对国产库现状的不足，在实施过程中可根据以下几个方面进行准备
1).制定开发规范
充分地了解国产数据库的技术特点，制定有针对性的设计开发规范。很多国产数据库基于多年实践，也都提供了开发规范，可以充分地予以吸纳。特别是针对分布式数据库，对开发有较多约束，要在系统设计、迁移之初就基于考虑。通常原则是尽量简化对数据库的使用，拒绝3B 大SQL(Big SQL) 大事务(Big transaction) 大批量(Big batch) 。
2).完善工具平台
基于国产数据库内核能力的不足，还需要较长一段时间来完善升级，可通过外部工具或平台的方式补齐内部短板。一方面可通过企业自研的方式增强对国产库的管理能力，一方面也可利用一些外围工具（如海信的DB Doctor、白鳝老师的D-Smart）来增强。
3).培养人与技能
要想使用好国产数据库，更多是需要人员及技能。目前国产数据库在生态建设方面还尚属初期阶段，需要企业内部独立培养更多的人并具备相应的技能。只要充分地了解理解数据库，才能更好地使用它。业内有某公司使用国产数据库，内部超千人通过认证培训的案例即说明了这点。
