SQL-Server性能调优之浅析SQL执行的过程 (sqlserver)

本篇文章的议题如下：

查询计划概述

很多时候，当我们在使用sql server的时候，做的事情非常简单：输入sql语句，然后执行，最后获取结果。下面，为了使得大家更加清楚的了解Sql server的内部机制，我们就重新来审视一个sql语句的执行。

把sql语句提到给了之后，数据库会执行一系列的内部处理，我们大致的可将内部的处理按照执行的顺序，划分为两个阶段：

在数据库的关系引擎中，sql 的查询语句会解析并且将解析的结果传递给后面的查询优化器，查询优化器负责生成执行计划。之后，执行计划(以二级制的格式)就会被传递到存储引擎里面，最后返回或更新底层的数据。

数据库的存储引擎会进行很多的操作，例如锁定，索引的维护，事务的处理等。

因为本系列文章主要的剖析执行计划，所以我们的关注点会放在关系引擎上面。

下面，我们就来稍微详细的讨论一个sql查询语句的执行过程。

查询解析

正如我们刚刚提到过：当把一个sql语句提交到了数据库以后，sql语句最先会被传入到关系引擎中。

当sql语句达到了关系引擎之后，首先要进行的操作就是检查sql语句的格式是否正确。这个处理过程就是我们常说的“解析”过程。解析过程的结果就是生成一个解析树，或者称为查询树。查询树反映了一个查询要执行的逻辑步骤，查询树的结构类似下面图中所示：

其实从编译原理的角度来看，这个解析过程就是文法和词法的解析，最后生成语法树。

有一点需要注意的就是：如果提交的sql语句不是一个数据操作语句(数据操作语句指Select，Insert，Update语句)，那么这个语句是不会被优化的。例如，如果提交的sql语句是创建一个数据表，那么这个语句是不会被优化的，而是直接执行。

如果提交的数据操作语句，那么之前由关系引擎创建的解析树就会传递给algebrizer组件执行绑定过程。在这个绑定过程过程中，这个algebrizer组件就会去检查解析树中的表名，列名是否都关联到了数据库中相应的表或对象的引用。

同时，algebrizer组件还负责确定解析树中的每个节点的类型是否和数据库中对应的是否一致。algebrizer组件以从下到上的方式开始遍历树，即，先从页级节点开始，也就是列和常量。

绑定解析是一个非常重要的过程，在这个过程中还会识别出我们自己定义的一些别名。这个过程执行完成之后，就会产生一个二进制的“查询处理树”，这个树会被传递给查询优化器。

查询优化器

查询优化器使用查询处理树和相关的统计信息来生成一个执行计划。

换句话说，查询优化器指出了如何最好的去执行提交的sql语句。查询优化器会决定是否可以采用索引来访问数据，采用那种类型的join操作会更好(例如，尽管我们有时候在sql中写的是Left Join，可能查询优化器在分析之后，在保证结果一样的前提下，采用Inner Join)。

查询优化器是一个基本成本分析的优化器。这意味着它会尝试为每个sql语句生成成本最低的执行计划。

另外，我们来归对于优化器所用到的统计数据进行简要的解析。所谓的统计数据，就是在数据库中描述列、索引相关信息的数据，即数据的数据，或称之为“元数据”。优化器就是结合统计数据和查询处理树来进行成本的估计的。

在默认的情况下，统计信息是由数据库内部自动的进行更新的(在调优的时候，可以手动的更新)。

需要提及的就是：表变量是没有任何的统计数据的，也就是说，如果对表变量中的数据进行查询，优化器是不做任何的优化的。但是临时表是有相应的统计数据的。

有一点需要注意的就是：上面的成本只是“估算”而已。一些复杂的语句可能会有很多个候选的执行计划，在这种情况下，查询优化器不会分析所有的组合，而是找出一个接近理论最小值的一个执行计划。计划的成本表现为估计完成查询所需的时间。最低估计成本不一定是最低的资源成本。

查询执行

一旦执行计划生成之后，操作就转入存储引擎中，这也是查询真正被执行的地方，也是根据估计执行计划 产生实际执行计划的产所。

查询计划的重用

从之前的一些步骤可以看到：Sql Server产生一个实际的执行计划需要很多的步骤和很多的成本(执行计划的过度编译往往成为一个很大的性能问题)，必须尽可能的重用执行计划(如果后文不做特殊说明，执行计划就指代“实际执行计划”)，所以，在数据库中，一旦执行计划产生之后，就被缓存在了内存中(称之为计划缓冲)。

正如之前所提到的，当优化器产生了估计的执行计划之后，计划就会被传递给存储引擎。其实在将估计的执行计划传给存储引擎之前，查询优化器就去“计划缓冲” 中查找与现在估计的执行计划对应的实际执行计划。如果找到了，那么，查询优化器将会使用执行计划传进行后续操作。这样就避免了重新生成实际的执行计划。

一般而言，每个查询的执行计划都只保存一个，除非查询优化器知道采用并行执行可以产生更好的性能，此时，并行查询的执行计划就被缓存起来，也就是说：同一个查询，在计划缓冲中有两个执行计划。

执行计划并不是永远被保存在内存中的。它们也是会过期的。SQL Server会基于最近最少使用的算法来移除那些不常用的执行计划。下面列出了执行计划被移除的几个条件：

注:熟悉.NET的朋友，可以将之与.NET的垃圾回收机制类比理解。

原文链接：

【编辑推荐】

Apache Flink和Apache Spark有什么异同？它们的发展前景分别怎样

flink是一个类似spark的“开源技术栈”，因为它也提供了批处理，流式计算，图计算，交互式查询，机器学习等。 flink也是内存计算，比较类似spark，但是不一样的是，spark的计算模型基于RDD，将流式计算看成是特殊的批处理，他的DStream其实还是RDD。 而flink吧批处理当成是特殊的流式计算，但是批处理和流式计算的层的引擎是两个，抽象了DataSet和DataStream。 flink在性能上也标新很好，流式计算延迟比spark少，能做到真正的流式计算，而spark只能是准流式计算。 而且在批处理上，当迭代次数变多，flink的速度比spark还要快，所以如果flink早一点出来，或许比现在的Spark更火。

SQL Server 2005的有哪些新特点

看看官方的介绍吧：SQL Server 2005 新增功能企业数据管理在当今的互联世界中，数据和管理数据的系统必须始终为 用户可用且能够确保安全。 有了 SQL Server 2005，组织内的用户和信息技术 (IT) 专家将从减少的应用程序停机时间、提高的可伸缩性及 性能、更紧密而灵活的安全控制中获益。 SQL Server 2005 也包括了许多新的和改进的功能来帮助 IT 工作人员更有效率地工作。 SQL Server 2005 包含几个在企业数据管理中关键的增强：易管理性SQL Server 2005 使部署、管理和优化企业数据以及分析应用程序变得更简单、更容易。 作为一个企业数据管理平台，它提供单 一管理控制台，使数据管理员能够在任何地方监视、管理和调谐企业中所有的数据库和相关的服务。 它还提供了一个可以使用 SQL 管理对象轻松编程的可扩展 的管理基础结构，使得用户可以定制和扩展他们的管理环境，同时使独立软件供应商 (ISV) 也能够创建附加的工具和功能来更好地扩展打开即得的能力。 SQL Server Management StudioSQL Server 2005 通 过提供一个集成的管理控制台来监视和管理 SQL Server 关系数据库、Integration Services、 Analysis Services、Reporting Services、Notification Services 以及在数量众多的分布式服务 器和数据库上的 SQL Server Mobile Edition，从而简化了管理工作。 数据库管理员能够同时执行多个任务，例如，编写和执行查询， 查看服务器对象，管理对象，监视系统活动和查看联机帮助。 SQL Server Management Studio 提供了一个开发环境，可在其中使 用 Transact-SQL、多维表达式、XML for Analysis 和 SQL Server Mobile Edition 来编写、编辑 和管理脚本和存储过程。 Management Studio 可以很容易地与源代码控制集成在一起。 Management Studio 还包括一些工具 可用来调度 SQL Server 代理作业和管理维护计划，以自动执行日常维护和操作任务。 管理和脚本编写集成在单一工具中，同时，该工具具有管理所有 类型的服务器的能力，为数据库管理员们提供了更强的生产效率。 SQL Server 2005 开放了 70 多个新的内部数据库性能和 资源使用的度量值，涵盖了从内存、锁定到对事务、网络和磁盘 I/O 的调度等。 这些动态管理视图 (DMV) 提供了对数据库和强大的基础结构的更大的 透明度和可见性，可以主动监视数据库的状况和性能。 SQL 管理对象SQL 管理对象 (SMO) 是一个新的可编程对象集，它 可实现所有 SQL Server 数据库的管理功能。 事实上，Management Studio 就是构建在 SQL 管理对象之上的。 SMO 是作 为 Microsoft Framework 程序集实现的。 您可以使用 SMO 自动执行常见的 SQL Server 管理任务，例如，用 编程方式检索配置设置，创建新数据库，应用 Transact-SQL 脚本，创建 SQL Server 代理作业以及调度备份等。 SMO 对象模型替 代了包含在 SQL Server 早期版本中的分布式管理对象 (DMO)，因为它更安全可靠并具有更高的可伸缩性。 可用性在 高可用性技术、额外的备份和恢复功能，以及复制增强上的投资使企业能够构建和部署高可用的应用程序。 在高可用性上的创新有：数据库镜像、故障转移群集、数 据库快照和增强的联机操作，这有助于最小化停机时间，并确保可以访问关键的企业系统。 本节将详细介绍这些增强特性。 数据库镜像数 据库镜像允许事务日志以连续的方式从源服务器传递到单台目标服务器上。 当主系统出现故障时，应用程序可以立即重新连接到辅助服务器上的数据库。 辅助实例几 秒钟内即可检测到主服务器发生了故障，并能立即接受数据库连接。 数据库镜像工作在标

oracle数据库的后台进程有哪些

DBWR进程：该进程执行将缓冲区写入数据文件，是负责缓冲存储区管理的一个ORACLE后台进程。 当缓冲区中的一缓冲区被修改，它被标志为“弄脏”，DBWR的主要任务是将“弄脏”的缓冲区写入磁盘，使缓冲区保持“干净”。 由于缓冲存储区的缓冲区填入数据库或被用户进程弄脏，未用的缓冲区的数目减少。 当未用的缓冲区下降到很少，以致用户进程要从磁盘读入块到内存存储区时无法找到未用的缓冲区时，DBWR将管理缓冲存储区，使用户进程总可得到未用的缓冲区。 ORACLE采用LRU（LEAST RECENTLY USED）算法（最近最少使用算法）保持内存中的数据块是最近使用的，使I/O最小。 在下列情况预示DBWR 要将弄脏的缓冲区写入磁盘：当一个服务器进程将一缓冲区移入“弄脏”表，该弄脏表达到临界长度时，该服务进程将通知DBWR进行写。 该临界长度是为参数DB-BLOCK-WRITE-BATCH的值的一半。 当一个服务器进程在LRU表中查找DB-BLOCK-MAX-SCAN-CNT缓冲区时，没有查到未用的缓冲区，它停止查找并通知DBWR进行写。 出现超时（每次3秒），DBWR 将通知本身。 当出现检查点时，LGWR将通知DBWR.在前两种情况下，DBWR将弄脏表中的块写入磁盘，每次可写的块数由初始化参数DB-BLOCK- WRITE-BATCH所指定。 如果弄脏表中没有该参数指定块数的缓冲区，DBWR从LUR表中查找另外一个弄脏缓冲区。 如果DBWR在三秒内未活动，则出现超时。 在这种情况下DBWR对LRU表查找指定数目的缓冲区，将所找到任何弄脏缓冲区写入磁盘。 每当出现超时，DBWR查找一个新的缓冲区组。 每次由DBWR查找的缓冲区的数目是为寝化参数DB-BLOCK- WRITE-BATCH的值的二倍。 如果数据库空运转，DBWR最终将全部缓冲区存储区写入磁盘。 在出现检查点时，LGWR指定一修改缓冲区表必须写入到磁盘。 DBWR将指定的缓冲区写入磁盘。 在有些平台上，一个实例可有多个DBWR.在这样的实例中，一些块可写入一磁盘，另一些块可写入其它磁盘。 参数DB-WRITERS控制DBWR进程个数。 LGWR进程：该进程将日志缓冲区写入磁盘上的一个日志文件，它是负责管理日志缓冲区的一个ORACLE后台进程。 LGWR进程将自上次写入磁盘以来的全部日志项输出，LGWR输出：当用户进程提交一事务时写入一个提交记录。 每三秒将日志缓冲区输出。 当日志缓冲区的1/3已满时将日志缓冲区输出。 当DBWR将修改缓冲区写入磁盘时则将日志缓冲区输出。 LGWR进程同步地写入到活动的镜象在线日志文件组。 如果组中一个文件被删除或不可用，LGWR 可继续地写入该组的其它文件。 日志缓冲区是一个循环缓冲区。 当LGWR将日志缓冲区的日志项写入日志文件后，服务器进程可将新的日志项写入到该日志缓冲区。 LGWR 通常写得很快，可确保日志缓冲区总有空间可写入新的日志项。 注意：有时候当需要更多的日志缓冲区时，LWGR在一个事务提交前就将日志项写出，而这些日志项仅当在以后事务提交后才永久化。 ORACLE使用快速提交机制，当用户发出COMMIT语句时，一个COMMIT记录立即放入日志缓冲区，但相应的数据缓冲区改变是被延迟，直到在更有效时才将它们写入数据文件。 当一事务提交时，被赋给一个系统修改号（SCN），它同事务日志项一起记录在日志中。 由于SCN记录在日志中，以致在并行服务器选项配置情况下，恢复操作可以同步。 CKPT进程：该进程在检查点出现时，对全部数据文件的标题进行修改，指示该检查点。 在通常的情况下，该任务由LGWR执行。 然而，如果检查点明显地降低系统性能时，可使CKPT进程运行，将原来由LGWR进程执行的检查点的工作分离出来，由 CKPT进程实现。 对于许多应用情况，CKPT进程是不必要的。 只有当数据库有许多数据文件，LGWR在检查点时明显地降低性能才使CKPT运行。 CKPT进程不将块写入磁盘，该工作是由DBWR完成的。 初始化参数CHECKPOINT-PROCESS控制CKPT进程的使能或使不能。 缺省时为FALSE，即为使不能。 SMON进程：该进程实例启动时执行实例恢复，还负责清理不再使用的临时段。 在具有并行服务器选项的环境下，SMON对有故障CPU或实例进行实例恢复。 SMON进程有规律地被呼醒，检查是否需要，或者其它进程发现需要时可以被调用。 PMON进程：该进程在用户进程出现故障时执行进程恢复，负责清理内存储区和释放该进程所使用的资源。 例：它要重置活动事务表的状态，释放封锁，将该故障的进程的ID从活动进程表中移去。 PMON还周期地检查调度进程（DISPATCHER）和服务器进程的状态，如果已死，则重新启动（不包括有意删除的进程）。 PMON有规律地被呼醒，检查是否需要，或者其它进程发现需要时可以被调用。 RECO进程：该进程是在具有分布式选项时所使用的一个进程，自动地解决在分布式事务中的故障。 一个结点RECO后台进程自动地连接到包含有悬而未决的分布式事务的其它数据库中，RECO自动地解决所有的悬而不决的事务。 任何相应于已处理的悬而不决的事务的行将从每一个数据库的悬挂事务表中删去。 当一数据库服务器的RECO后台进程试图建立同一远程服务器的通信，如果远程服务器是不可用或者网络连接不能建立时，RECO自动地在一个时间间隔之后再次连接。 RECO后台进程仅当在允许分布式事务的系统中出现，而且DISTRIBUTED ？C TRANSACTIONS参数是大于进程：该进程将已填满的在线日志文件拷贝到指定的存储设备。 当日志是为ARCHIVELOG使用方式、并可自动地归档时ARCH进程才存在。 LCKn进程：是在具有并行服务器选件环境下使用，可多至10个进程（LCK0，LCK1……，LCK9），用于实例间的封锁。 Dnnn进程（调度进程）：该进程允许用户进程共享有限的服务器进程（SERVER PROCESS）。 没有调度进程时，每个用户进程需要一个专用服务进程（DEDICATEDSERVER PROCESS）。 对于多线索服务器（MULTI-THREADED SERVER）可支持多个用户进程。 如果在系统中具有大量用户，多线索服务器可支持大量用户，尤其在客户_服务器环境中。 在一个数据库实例中可建立多个调度进程。 对每种网络协议至少建立一个调度进程。 数据库管理员根据操作系统中每个进程可连接数目的限制决定启动的调度程序的最优数，在实例运行时可增加或删除调度进程。 多线索服务器需要SQL*NET版本2或更后的版本。 在多线索服务器的配置下，一个网络接收器进程等待客户应用连接请求，并将每一个发送到一个调度进程。 如果不能将客户应用连接到一调度进程时，网络接收器进程将启动一个专用服务器进程。 该网络接收器进程不是ORACLE实例的组成部分，它是处理与ORACLE有关的网络进程的组成部分。 在实例启动时，该网络接收器被打开，为用户连接到ORACLE建立一通信路径，然后每一个调度进程把连接请求的调度进程的地址给予于它的接收器。 当一个用户进程作连接请求时，网络接收器进程分析请求并决定该用户是否可使用一调度进程。 如果是，该网络接收器进程返回该调度进程的地址，之后用户进程直接连接到该调度进程。 有些用户进程不能调度进程通信（如果使用SQL*NET以前的版本的用户），网络接收器进程不能将如此用户连接到一调度进程。 在这种情况下，网络接收器建立一个专用服务器进程，建立一种合适的连接.即主要的有：DBWR,LGWR,SMON 其他后台进程有PMON,CKPT等