Nothing happened !
前言
上一篇我们分析了查询优化器的工作方式，其中包括：查询优化器的详细运行步骤、筛选条件分析、索引项优化等信息。
本篇我们分析在我们运行的过程中几个关键指标值的检测。
通过这些指标值来分析语句的运行问题，并且分析其优化方式。
通过本篇我们可以学习到调优中经常利用的几个利器！
废话少说，开始本篇的正题。
技术准备
数据库版本为SQL Server2008R2，利用微软的一个更简洁的案例库（Northwind）进行分析。
利器一、IO统计
通过这个IO统计能为我们分析出当前查询语句所要扫描的数据页的数量。这里面有几个重要的概念，我们依次分析。
方法很简单，一行代码搞定：
SET STATISTICS IO ON
来看个例子
SET STATISTICS IO ON GO SELECT * FROM Person.Contact
这里可以看到这个语句对于数据表的操作次数，基于数据页的扫描项。 Continue reading “SQL Server调优系列进阶篇（查询语句运行几个指标值监测）”
前言
前面我们的几篇文章介绍了一系列关于运算符的基础介绍，以及各个运算符的优化方式和技巧。其中涵盖：查看执行计划的方式、几种数据集常用的连接方式、联合运算符方式、并行运算符等一系列的我们常见的运算符。有兴趣的童鞋可以点击查看。
本篇介绍在SQL Server中查询优化器的工作方式，也就是一个好的执行计划的形成，是如何评估出来的，作为该系列的进阶篇。
废话少说，开始本篇的正题。
技术准备
数据库版本为SQL Server2008R2，利用微软的一个更简洁的案例库（Northwind）进行分析。
正文内容
在我们将写好的一个T-SQL语句抛给SQL Server准备执行的时候，首选要经历的过程就是编译过程，当然如果此语句以前在SQL Server中执行过，那么将检测是否存在已经缓存的编译过的执行计划，用以重用。
但是，执行编译的过程需要执行一系列的优化过程，关于优化过程大致分为两个阶段：
1、首先，SQL Server对我们写的T-SQL语句先执行一些简化，通常由查询本身来寻找交互性及重新安排操作的顺序。
在此过程中，SQL Server侧重于语句写法调整，而不过多的考虑成本或者分析索引可用性的等，最重要的目标就是产生一个有效的查询。
然后，SQL Server才会加载元数据，包括索引的统计信息，进入第二个阶段。
2、在这个阶段才是SQL Server一个复杂的优化过程，这个阶段SQL Server会根据上一阶段形成的执行计划运算符进行评估和尝试，甚至于重组执行计划，所以相对这个优化过程是一个耗时的过程。
通过如下流程图，来理解该过程：
前言
前面我们的几篇文章介绍了一系列关于运算符的介绍，以及各个运算符的优化方式和技巧。其中涵盖：查看执行计划的方式、几种数据集常用的连接方式、联合运算符方式、并行运算符等一系列的我们常见的运算符。有兴趣的童鞋可以点击查看。
本篇我们介绍关于子查询语句的一系列内容，子查询一般是我们形成复杂查询的一些基础性操作，所以关于子查询的应用方式就非常重要。
废话少说，开始本篇的正题。
技术准备
数据库版本为SQL Server2008R2，利用微软的一个更简洁的案例库（Northwind）进行分析。
一、独立的子查询方式
所谓的独立的子查询方式，就是说子查询和主查询没有相关性，这样带来的好处就是子查询不依赖于外部查询，所以可以独立外部查询而被评估，形成自己的执行计划执行。
举个例子
SELECT O1.OrderID,O1.Freight FROM Orders O1 WHERE O1.Freight> ( SELECT AVG(O2.Freight) FROM Orders O2 )
这句SQL执行的目标是查询订单中运费大于平均运费数的订单。
这里提取平均运费的子句就是一个完全独立的子查询，完全不依赖主查询而独立执行。同时这里我们这里利用利用一个标量计算（AVG），因此正好返回一行。
查看一下该语句的查询计划：
这个查询计划没啥好介绍的，关于子查询的执行计划形成可以参照我的第二篇：SQL Server调优系列基础篇（常用运算符总结） Continue reading “SQL Server调优系列基础篇（子查询运算总结）”
前言
上几篇文章我们介绍了如何查看查询计划、常用运算符的介绍、并行运算的方式，有兴趣的可以点击查看。
本篇将分析在SQL Server中，如何利用先有索引项进行查询性能优化，通过了解这些索引项的应用方式可以指导我们如何建立索引、调整我们的查询语句，达到性能优化的目的。
闲言少叙，进入本篇的正题。
技术准备
基于SQL Server2008R2版本，利用微软的一个更简洁的案例库（Northwind）进行解析。
简介
所谓的索引应用就是在我们日常写的T-SQL语句中，如何利用现有的索引项，再分析的话就是我们所写的查询条件，其实大部分情况也无非以下几种：
1、等于谓词：select …where…column=@parameter
2、比较谓词：select …where…column> or < or <> or <= or >= @parameter
3、范围谓词：select …where…column in or not in or between and @parameter
4、逻辑谓词：select …where…一个谓词 or、and 其它谓词 or、and 更多谓词….
我们就依次分析上面几种情况下，如何利用索引进行查询优化的
一、动态索引查找
所谓的动态索引查找就是SQL Server在执行语句的时候，才格式化查询条件，然后根据查询条件的不同自动的去匹配索引项，达到性能提升的目的。
来举个例子
SET SHOWPLAN_TEXT ON GO SELECT OrderID FROM Orders WHERE ShipPostalCode IN (N'05022',N'99362')
前言
上一篇文章我们介绍了查看查询计划的并行运行方式。
本篇我们接着分析SQL Server的并行运算。
闲言少叙，直接进入本篇的正题。
技术准备
同前几篇一样，基于SQL Server2008R2版本，利用微软的一个更简洁的案例库（Northwind）进行解析。
内容
文章开始前，我们先来回顾上一篇中介绍的并行运算，来看文章最后介绍的并行运算语句：
SELECT B1.[KEY],B1.DATA,B2.DATA FROM BigTable B1 JOIN BigTable2 B2 ON B1.[KEY]=B2.[KEY] WHERE B1.DATA<100
上面是详细的执行计划，从右边依次向左执行，上图中有一个地方很有意思，就是在聚集索引扫描后获取的数据，又重新了使用了一次重新分配任务的过程（Repartition Streams），就是上图的将获取的100行数据重新分配到并行的各个线程中。 Continue reading “SQL Server调优系列基础篇（并行运算总结篇二）”
前言
上三篇文章我们介绍了查看查询计划的方式，以及一些常用的连接运算符、联合运算符的优化技巧。
本篇我们分析SQL Server的并行运算，作为多核计算机盛行的今天，SQL Server也会适时调整自己的查询计划，来适应硬件资源的扩展，充分利用硬件资源，最大限度的提高性能。
闲言少叙，直接进入本篇的正题。
技术准备
同前几篇一样，基于SQL Server2008R2版本，利用微软的一个更简洁的案例库（Northwind）进行解析。
一、并行运算符
在我们日常所写的T-SQL语句，并不是所有的最优执行计划都是一样的，其最优的执行计划的形成需要多方面的评估才可以，大部分根据SQL Server本身所形成的统计信息，然后对形成的多个执行计划进行评估，进而选出最优的执行方式。
在SQL Server根据库内容形成的统计信息进行评估的同时，还要参照当前运行的硬件资源，有时候它认为最优的方案可能当前硬件资源不支持，比如：内存限制、CPU限制、IO瓶颈等，所以执行计划的优劣还要依赖于底层硬件。
当SQL Server发现某个处理的数据集比较大，耗费资源比较多时，但此时硬件存在多颗CPU时，SQL Server会尝试使用并行的方法，把数据集拆分成若干个，若干个线程同时处理，来提高整体效率。
在SQL Server中可以通过如下方法，设置SQL Server可用的CPU个数
默认SQL Server会自动选择CPU个数，当然不排除某些情况下，比如高并发的生产环境中，防止SQL Server独占所有CPU，所以提供了该配置的界面。 Continue reading “SQL Server调优系列基础篇（并行运算总结一）”
前言
上两篇文章我们介绍了查看查询计划的方式，以及一些常用的连接运算符的优化技巧，本篇我们总结联合运算符的使用方式和优化技巧。
废话少说，直接进入本篇的主题。
技术准备
基于SQL Server2008R2版本，利用微软的一个更简洁的案例库（Northwind）进行解析。
一、联合运算符
所谓的联合运算符，其实应用最多的就两种：UNION ALL和UNION。
这两个运算符用法很简单，前者是将两个数据集结果合并，后者则是合并后进行去重操作，如果有过写T-SQL语句的码农都不会陌生。
我们来分析下这两个运算符在执行计划中的显示，举个例子
SELECT FirstName+N''+LastName,City,Country FROM Employees UNION ALL SELECT ContactName,City,Country FROM Customers
就是上面这个图标了，这就是UNION ALL联合运算符的图标。
前言
上一篇我们介绍了如何查看查询计划，本篇将介绍在我们查看的查询计划时的分析技巧，以及几种我们常用的运算符优化技巧，同样侧重基础知识的掌握。
通过本篇可以了解我们平常所写的T-SQL语句，在SQL Server数据库系统中是如何分解执行的，数据结果如何通过各个运算符组织形成的。
技术准备
基于SQL Server2008R2版本，利用微软的一个更简洁的案例库（Northwind）进行解析。
一、数据连接
数据连接是我们在写T-SQL语句的时候最常用的，通过两个表之间关联获取想要的数据。
SQL Server默认支持三种物理连接运算符：嵌套循环连接、合并连接以及哈希连接。三种连接各有用途，各有特点，不同的场景会数据库会为我们选择最优的连接方式。
a、嵌套循环连接（nested loops join)
嵌套循环连接是最简单也是最基础的连接方式。两张表通过关键字进行关联，然后通过双层循环依次进行两张表的行进行关联，然后通过关键字进行筛选。
可以参照下图进行理解分析
其实嵌套扫描是很简单的获取数据的方式，简单点就是两层循环过滤出结果值。
我们可以通过如下代码加深理解
for each row R1 in the outer table
for each row R2 int the inner table
if R1 join with R2
return (R1,R2)
举个列子 Continue reading “SQL Server调优系列基础篇（常用运算符总结——三种物理连接方式剖析）”
1.区:
区是SQL Server 中管理空间的基本单位。
一个区是八个物理上连续的页（即 64 KB）, 所有页都存储在区中, 这意味着 SQL Server 数据库中每 MB 有 16 个区。 一旦一个区段已满, 下一条数据Sql server将分配一个区段空间, 防止每次添加都要分配空间.
2.页（Page）:
页是SQL Server 中数据存储的基本单位, 它是区段的分配单元, 一页8K, 它下面就是数据行了, 但每页的行数不定, 这取决于数据行的大小.
数据库中的数据文件（.mdf 或 .ndf）分配的磁盘空间可以从逻辑上划分成页（从 0 到 n 连续编号）。磁盘 I/O 操作在页级执行。也就是说，SQL Server 每次读取或写入数据的最少数据单位是数据页。
每页的开头是 96 字节的标头，用于存储有关页的系统信息。此信息包括页码、页类型、页的可用空间以及拥有该页的对象的分配单元 ID。
在 SQL Server 中，页的大小为 8 KB。这意味着 SQL Server 数据库中每 MB 有 128 页。依次类推。根据数据库的文件大小，我们可以算出数据库有多少数据页。
3.页的类型: 数据页, 索引页, Blob页等等.
4.行: 因为行存于页中,因此, 一行的大小通常最多8K(8060字符, 一页的上限), 一行最大列数为1024列(字段).
如果是varchar(max), text, image时, 可以跨越多页, 一行最大2GB, 此时, 原始的行用来存放指针及其它列.
5.全文目录: 虽然和sql server在一起, 但实际上该目录是独立存放在磁盘上的.
6.索引: 是与表或视图关联的磁盘上的结构，可以加快从表或视图中检索行的速度。
它包含由表或视图中的一列或多列生成的键。这些键存储在一个结构（B 树）中，使 SQL Server 可以快速有效地查找与键值关联的行。
7.索引的类型：聚集, 非聚集.
另外还有唯一索引, 唯一索引确保索引键不包含重复的值，因此，表或视图中的每一行在某种程度上是唯一的。
聚集索引和非聚集索引都可以是唯一索引。
8.聚集索引: 根据数据行的键值在表或视图中排序和存储这些数据行。
每个表只能有一个聚集索引，因为数据行本身只能按一个顺序排序。
只有当表包含聚集索引时，表中的数据行才按排序顺序存储。如果表具有聚集索引，则该表称为聚集表。
如果表没有聚集索引，则其数据行存储在一个称为堆的无序结构中。
即聚集表是有聚集索引的表，堆是没有聚集索引的表。
索引视图与聚集表具有相同的存储结构。
聚集索引的叶节点就是实际的数据页。
聚集索引的平均大小大约为表大小的5%左右。
9.非聚集索引：
每个表最多可以有249个非聚集索引.
10.索引的维护：每当修改了表数据后，都会自动维护表或视图的索引。
11.索引和约束: 对表列定义了 PRIMARY KEY 约束和 UNIQUE 约束时，会自动创建索引。
下面摘自MSDN:
SQL Server 中数据存储的基本单位是页。为数据库中的数据文件（.mdf 或 .ndf）分配的磁盘空间可以从逻辑上划分成页（从 0 到 n 连续编号）。磁盘 I/O 操作在页级执行。也就是说，SQL Server 读取或写入所有数据页。
区是八个物理上连续的页的集合，用来有效地管理页。所有页都存储在区中。
在 SQL Server 中，页的大小为 8 KB。这意味着 SQL Server 数据库中每 MB 有 128 页。每页的开头是 96 字节的标头，用于存储有关页的系统信息。此信息包括页码、页类型、页的可用空间以及拥有该页的对象的分配单元 ID。
下表说明了 SQL Server 数据库的数据文件中所使用的页类型。
| 页类型 | 内容 |
|---|---|
| Data | 当 text in row 设置为 ON 时，包含除 text、 ntext、image、nvarchar(max)、varchar(max)、varbinary(max) 和 xml 数据之外的所有数据的数据行。 |
| Index | 索引条目。 |
| Text/Image | 大型对象数据类型：
数据行超过 8 KB 时为可变长度数据类型列：
|
| Global Allocation Map、Shared Global Allocation Map | 有关区是否分配的信息。 |
| Page Free Space | 有关页分配和页的可用空间的信息。 |
| Index Allocation Map | 有关每个分配单元中表或索引所使用的区的信息。 |
| Bulk Changed Map | 有关每个分配单元中自最后一条 BACKUP LOG 语句之后的大容量操作所修改的区的信息。 |
| Differential Changed Map | 有关每个分配单元中自最后一条 BACKUP DATABASE 语句之后更改的区的信息。 |
| 注意 |
|---|
| 日志文件不包含页，而是包含一系列日志记录。 |
在数据页上，数据行紧接着标头按顺序放置。页的末尾是行偏移表，对于页中的每一行，每个行偏移表都包含一个条目。每个条目记录对应行的第一个字节与页首的距离。行偏移表中的条目的顺序与页中行的顺序相反。
行不能跨页，但是行的部分可以移出行所在的页，因此行实际可能非常大。页的单个行中的最大数据量和开销是 8,060 字节 (8 KB)。但是，这不包括用 Text/Image 页类型存储的数据。包含 varchar、nvarchar、varbinary 或 sql_variant 列的表不受此限制的约束。当表中的所有固定列和可变列的行的总大小超过限制的 8,060 字节时，SQL Server 将从最大长度的列开始动态将一个或多个可变长度列移动到 ROW_OVERFLOW_DATA 分配单元中的页。每当插入或更新操作将行的总大小增大到超过限制的 8,060 字节时，将会执行此操作。将列移动到 ROW_OVERFLOW_DATA 分配单元中的页后，将在 IN_ROW_DATA 分配单元中的原始页上维护 24 字节的指针。如果后续操作减小了行的大小，SQL Server 会动态将列移回到原始数据页。有关详细信息，请参阅行溢出数据超过 8 KB。
区是管理空间的基本单位。一个区是八个物理上连续的页（即 64 KB）。这意味着 SQL Server 数据库中每 MB 有 16 个区。
为了使空间分配更有效，SQL Server 不会将所有区分配给包含少量数据的表。SQL Server 有两种类型的区：
通常从混合区向新表或索引分配页。当表或索引增长到 8 页时，将变成使用统一区进行后续分配。如果对现有表创建索引，并且该表包含的行足以在索引中生成 8 页，则对该索引的所有分配都使用统一区进行。
小到中等大小的大值类型（varchar(max)、nvarchar(max)、varbinary(max) 和 xml）和大型对象 (LOB) 数据类型（text、ntext 和 image）都可以存储在数据行中。该行为可以通过在 sp_tableoption 系统存储过程中使用以下两个选项来控制：用于大值类型的 large value types out of row 选项，以及用于大型对象类型的 text in row 选项。这两个选项最适用于这样的表：其中上述任意一种数据类型的数据值通常在一个单元中读/写，并且引用表的大多数语句都将引用此类数据。在行内存储的数据不一定有用，这取决于使用情况或工作负荷特征。
除非 text in row 选项设置为 ON 或特定的行内限制，否则 text、ntext 或 image 字符串都将是在数据行外存储的大型字符或二进制字符串（最多 2 GB）。数据行只包括一个 16 字节的文本指针，该指针指向一个内部指针构成的树的根节点。这些指针映射存储字符串片段的页。有关 text、ntext 或 image 字符串存储的详细信息，请参阅使用 Text 和 Image 数据。
可以为包含 LOB 数据类型列的表设置 text in row 选项。还可以指定 text in row 选项限制，范围从 24 到 7,000 字节。
同样，除非 large value types out of row 选项设置为 ON，否则会尽可能将 varchar(max)、nvarchar(max)、varbinary(max) 和 xml 列存储在数据行内。如果如此设置，则可以的话 SQL Server 数据库引擎将尝试容纳此特定值，否则会将其推到行外。如果 large value types out of row 设置为 ON，则上述值将存储在行外而只有 16 字节的文本指针存储在记录中。
| 注意 |
|---|
| 当 large value types out of row 设置为 OFF 时，用于大型值数据类型的最大行内存储量设置为 8,000 字节。与 text in row 选项不同，您不能指定表中列的行内限制。 |
将表配置为直接在数据行中存储大型值类型或大型对象数据类型时，如果存在以下情况之一，实际的列值都将存储在行内：
当大型值类型或大型对象数据类型列值存储在数据行中时，数据库引擎不必访问单独的页或页集来读/写字符或二进制字符串。这便使读/写行内字符串的速度与读/写大小受限制的 varchar、nvarchar 或 varbinary 字符串的速度大致一样。同样，当值存储在行外时，数据库引擎将引发读/写附加页。
对于大型对象数据类型，如果存储字符串所需的空间比 text in row 选项限制或行中的可用空间大，则本应存储在指针树根节点中的指针集将存储在行中。如果存在以下情况之一，指针将存储在行中：
当指针从根节点移至行本身时，数据库引擎不需要使用根节点。这样便可以在读/写字符串时不必访问页。从而可以提高性能。
如果使用根节点，它们将存储为 LOB 页中的一个字符串片段，并且最多可以包含 5 个内部指针。数据库引擎需要行具有 72 字节的空间来存储行内字符串的五个指针。如果 text in row 选项为 ON 或 large value types out of row 选项为 OFF 时行中没有足够的空间来容纳指针，数据库引擎可能必须分配一个 8K 的页来容纳它们。如果值的数据长度超过 40,200 字节，则需要 5 个以上的行内指针，此时只有 24 字节存储在主行中，而其他数据页被分配在 LOB 存储空间中。
当大型字符串存储在行中时，它们将与可变长度字符串的存储方式相似。数据库引擎将对列按大小以降序排序，并将值推到行外，直到剩余的列容纳在数据页 (8K) 中。
一个表中的每一行最多可以包含 8,060 字节。在 SQL Server 2008 中，对于包含 varchar、nvarchar、varbinary、sql_variant 或 CLR 用户定义类型列的表，可以放宽此限制。其中每列的长度仍必须在 8,000 字节的限制内，但是它们的总宽可以超过 8,060 字节的限制。创建和修改 varchar、nvarchar、varbinary、sql_variant 或 CLR 用户定义类型的列以及更新或插入数据时，此限制适用于上述列。
当合并每行超过 8060 字节的 varchar、nvarchar、varbinary、sql_variant 或 CLR 用户定义类型的列时，请注意下列事项：
前言
关于SQL Server调优系列是一个庞大的内容体系，非一言两语能够分析清楚，本篇先就在SQL 调优中所最常用的查询计划进行解析，力图做好基础的掌握，夯实基本功！而后再谈谈整体的语句调优。
通过本篇了解如何阅读和理解查询计划、并且列举一系列最常用的查询执行运算符。
技术准备
基于SQL Server2008R2版本，利用微软的一个更简洁的案例库（Northwind）进行解析。
一、区别不同的运算符
在所有T-SQL语句在执行的时候，都会将语句分解为一些基本的结构单元，这些结构单元统称为：运算符。每一个运算符都实现一个单独的基本操作，比 如：表扫描、索引查找、索引扫描、过滤等。每个运算符可以循环迭代，也可以延续子运算符，这样就可以组成查询树，即：查询计划。
每个T-SQL语句都会通过多种运算符进行组合形成不同的查询计划，并且这些查询计划对于结果的筛选都是有效的，但在执行的时候，SQL Server的查询优化器会自动为我们找到一个最优的。
每一个运算符都会有源数据的传入和结果数据的输出，源数据的输入可以来源于其它的运算符或者直接从数据源表中读取，经过本身的运算进行结果的输出。所以每一个运算符是独立的。互不关心的。
如下例子
SELECT COUNT(*) FROM Orders
此语句会生成两个简单的运算符
