SQL Server 性能优化实战系列

Posted 2021-01-24 大西瓜3721

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了SQL Server 性能优化实战系列相关的知识，希望对你有一定的参考价值。

SQL Server datetime数据类型设计、优化误区

一、场景

在SQL Server 2005中，有一个表TestDatetime，其中Dates这个字段的数据类型是datetime，如果你看到表的记录如下图所示，你最先想到的是什么呢？

（图1：数据列表）

你看到这些数据，是不是觉得这样的设计既浪费了存储空间，又使得这个列的索引增大，查询起来更慢，你也想使用一些其它的数据类型来代替这个datetime吧？

其实大家都是这么想的，这个方向是100%正确的，但是在写这篇文章以前，我进入了两个误区：（如果你中了下面的两个误区，那么请你看看这篇文章吧。）

误区一： 把Dates字段的datetime数据类型换成smalldatetime，这样数据就由：‘2009-04-09 00:00:00.000’变为‘2009-04-09 00:00:00’，这个看起来没有减少多少存储空间哦。

误区二：把Dates字段的datetime数据类型换成char(10)，这样数据就由：‘2009-04-09 00:00:00.000’变为‘2009-04-09’，这好像能减少很多存储空间哦。

二、分析

在SQL Server 2005版本中保存日期的数据类型只有两种：datetime、smalldatetime，但是在SQL Server 2008版本中新增了一些日期数据类型：time、date、smalldatetime、datetime、datetime2、datetimeoffset，其中的date类型就能满足我们场景中的需求了，如果你幸运的在使用SQL Server 2008的话，那么恭喜你，请使用date数据类型吧。

但是我就比较可悲一点了，在使用SQL Server 2005的前提下，我进入了误区一、误区二。其实这也是因为自己忽略了一下基础性的东西，如果知道不同数据类型的存储空间大小，也许就很轻易的避免这样低级的错误了。

其实你查看表TestDatetime中的Dates字段的时候，看到查询结果中的：“-”、“:”只是用于显示的，并不是真实保存的时候就这样格式的。

datetime占用8个字节，前4个字节存储base date（即1900年1月1日）之前或之后的天数，后4个字节存储午夜后的毫秒数。值范围：1753-01-01 到 9999-12-31。

smalldatetime占用4个字节，前2个字节存储base date（1900年1月1日）之后的天数。后2个字节存储午夜后的分钟数。值范围：1900-01-01 到 2079-06-06。

date占用3个字节，它比smalldatetime的前2个字节多了1字节，所以值的范围更广了。值范围：0001-01-01 到 9999-12-31。

所以，如果你使用char(10)来保存截断的日期，那么你的存储空间反而更大了。

结论：如果是SQL Server 2005，那么请你使用smalldatetime吧，数据能节约一半，虽然查询的时候看起来没什么改变；如果你是SQL Server 2008，那么请你使用date吧，

虽然3个字节跟4个字节没有多大的差距，但是从设计上和逻辑清晰度上都有很大的提升，而且差距有些时候并不是1个字节的问题，比如当表数据量达到几个亿的时候，还是有差别的，又或者一条记录可能因为差1个字节就刚刚好给8060字节的页瓜分，这些都不容忽视的。

三、测试

下面我们就从数据存储的大小、索引存储的大小、索引使用时候的速度这几个方面进行测试：（这里只测试数据类型：，，数据的内容都是一样的）

(一) 测试前奏：

创建三种数据类型char(10)、datetime、smalldatetime的表；（表结构如下面SQL）
插入相同记录到三个表中；（这里插入1210000条记录）
为[Dates]字段创建索引；（在创建索引的时候可以设置填充因子为100%）
查看索引属性中的索引碎片信息，查看表数据和索引占用的空间，测试[Dates]字段索引的查询效率；

CREATE TABLE [dbo].[TestDatetime](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [Dates] [datetime] NULL,
 CONSTRAINT [PK_TestDatetime] PRIMARY KEY CLUSTERED
(
    [Id] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

(二) 测试结果：

数据存储大小：

（图2：数据空间对比）

索引存储信息：

（图3：char(10)）

（图4：datetime）

（图5：smalldatetime）

索引查询的情况：

多次执行，SQL Server执行时间为：[char(10)] 大部分在43~59徘徊，偶尔出现小于10的；[datetime]平均在1~2毫秒；[smalldatetime]均在1毫秒；而且大家会发现[smalldatetime]有其它的9次逻辑读取变为8次了。

--[TestChar10]

SQL Server 分析和编译时间:

CPU 时间= 0 毫秒，占用时间= 1 毫秒。

(2200 行受影响)

表\'TestChar10\'。扫描计数1，逻辑读取9 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。

SQL Server 执行时间:

CPU 时间= 0 毫秒，占用时间= 59 毫秒。

SQL Server 执行时间:

CPU 时间= 0 毫秒，占用时间= 1 毫秒。

--[TestDatetime]

SQL Server 分析和编译时间:

CPU 时间= 0 毫秒，占用时间= 1 毫秒。

(2200 行受影响)

表\'TestDatetime\'。扫描计数1，逻辑读取9 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。

SQL Server 执行时间:

CPU 时间= 0 毫秒，占用时间= 2 毫秒。

SQL Server 执行时间:

CPU 时间= 0 毫秒，占用时间= 1 毫秒。

--[TestSmalldatetime]

SQL Server 分析和编译时间:

CPU 时间= 0 毫秒，占用时间= 1 毫秒。

(2200 行受影响)

表\'TestSmalldatetime\'。扫描计数1，逻辑读取8 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。

SQL Server 执行时间:

CPU 时间= 0 毫秒，占用时间= 1 毫秒。

SQL Server 执行时间:

CPU 时间= 0 毫秒，占用时间= 1 毫秒。

--SQL Server 2008新数据类型
SELECT
CAST(\'2007-05-08 12:35:29. 1234567 +12:15\' AS time(7)) AS \'time\'
,CAST(\'2007-05-08 12:35:29. 1234567 +12:15\' AS date) AS \'date\'
,CAST(\'2007-05-08 12:35:29.123\' AS smalldatetime) AS\'smalldatetime\'
,CAST(\'2007-05-08 12:35:29.123\' AS datetime) AS \'datetime\'
,CAST(\'2007-05-08 12:35:29. 1234567 +12:15\' AS datetime2(7)) AS \'datetime2\'
,CAST(\'2007-05-08 12:35:29.1234567 +12:15\' AS datetimeoffset(7)) AS \'datetimeoffset\';

四、参考文献

日期和时间数据类型及函数 (Transact-SQL)

LEN (Transact-SQL)

DATALENGTH (Transact-SQL)

smalldatetime和datetime存储

SQL Server 空间换时间的数据库设计

　我们的系统中很常会用到SMS、Email等的发送，在我们的设计中通常会创建一个Tb_outbox表，当产生数据时，插入到Tb_outbox表，由定时器去读取Tb_outbox的数据进行发送，发送完了再修改Tb_outbox的发送状态。是的，这就是通常的做法，但是当我们的SMS、Email的发送频率和数量足够大的时候，我们的系统就会出现性能、表被锁等问题。那我们如何是好呢？

　　下面的设计的一个思想就是如标题所述：空间换时间。就个人而言，我感觉这个描述更加贴切：对象的职责分离，把Insert、Update、Delete等分离在不同的表中。废话不多说，下面就来看看这个设计图：

图：逻辑图

Tb_NotSent_buffer：待发送短信缓存表(即时清理).

该表是为了避免应用过多对Tb_NotSent同时操作产生锁表情况。
主要考虑到产生待发短信的逻辑通常会比较复杂,或者长事务。
一次性将已经在buffer表里的短信insert到Tb_NotSent,这次插入没有长事务计算,由一条insert from select完成。
该表并非一定用到,视乎产生待发短信的逻辑的事务复杂度,和量而定。

Tb_NotSent：待发送的短信(会被定时清理)

会将该已经发送的短信的处理结果存储在jms消息队列里。
把这些数据从Tb_NotSent copy到Tb_outbox同时,插一条记录到Tb_Sent.这样作是为了下一步删除Tb_NotSent里已经发送的信息.同时又不因为删除而锁Tb_NotSent表(应用使用)
使用空间换时间的思想,减少对同一张表(Tb_outbox)的过多操作和过程时间的操作,导致锁表出现系统瓶颈。

Tb_outbox：存储历史记录的主表,该表需建立在独立的数据库。

减少备份文件大小，可灵活调整,大大减少备份空间的需求。
减少对主数据库的影响。

Tb_Sent：一个参照表，为删除Tb_NotSent表做基表

已经发送短信(会定时清理),存放已经被网关处理的短信(发送成功或者失败)。
这个表不一定要保存和Tb_NotSent一样多的字段，也许只要两个字段，那就是ID值和状态值。

SQL Server 即时文件初始化

一.本文所涉及的内容（Contents）

二.背景（Contexts）

数据库服务器在为表分配初始值的时候很慢，分配初始值40GB的数据文件，花了30多分钟，一开始的时候一直认为是服务器磁盘的写入速度太慢造成的，后来经过北京-宋沄剑的提醒：即时文件初始化(Instant File Initialization)，设置这一选项之后，速度提升到了19秒，下面将描述这个优化的设置过程。

三.基础知识（Rudimentary Knowledge）

就数据库而言，以下几种情况需要对文件初始化：

1. 创建数据库；

2. 向现有数据库中添加文件、日志或数据；

3. 增大现有文件的大小（包括自动增长操作）；

4. 还原数据库或文件组；

　　执行上面的操作，操作系统需要用零来填充文件进行初始化。在 SQL Server 中，可以在瞬间对数据文件进行初始化。即时文件初始化将回收已使用的磁盘空间而不使用零来填充该空间。而在向文件中写入新数据时，磁盘内容将被覆盖。日志文件不能立即初始化。

　　即时文件初始化功能仅在向 SQL Server (MSSQLSERVER) 服务帐户授予了 SE_MANAGE_VOLUME_NAME 之后才可用。Windows Administrator 组的成员拥有此权限，并可以通过将其他用户添加到【执行卷维护任务】安全策略中来为其授予此权限。

四.实现过程（Process）

首先运行gpedit.msc，按照Figure1的路径，找到【执行卷维护任务】，如Figure2所示，默认的情况下它已经设置了Administrators组的；

（Figure1：gpedit.msc）

（Figure2：执行卷维护任务）

接着运行services.msc进入服务设置，查看到SQL Server (MSSQLSERVER)的登陆用户是【网络服务】（如Figure3所示），这就是造成初始化40GB文件花费了30多分钟的原因了，因为【网络服务】不具备SE_MANAGE_VOLUME_NAME的权限（可查看Administrators组成员）；

（Figure3：SQL Server (MSSQLSERVER)）

双击SQL Server (MSSQLSERVER)服务进入设置，在登陆的选项卡中可以看到帐号是：NT AUTHORITY\\NETWORKSERVICE，如Figure4所示。

（Figure4：NT AUTHORITY\\NETWORKSERVICE）

直接勾选【本地系统帐号】，在重启SQL Server (MSSQLSERVER)时遇到了下图的错误：

（Figure5：重启服务报错）

查看了相关的系统事件日志，在SQL Server服务无法使用管理员身份启动中解决了（禁用掉SQL Server的协议Shared Memory），设置完之后重启服务SQL Server (MSSQLSERVER)。

而另外一种思路就是把NT AUTHORITY\\NETWORKSERVICE加入到Administrators组中，如Figure6所示。注意：这种方式一样需要重启SQL Server (MSSQLSERVER)服务。

（Figure6：Administrators组）

下面我们就来测试下创建40GB文件的性能对比：

--测试即时文件初始化
CREATE DATABASE [TestFileInit] ON  PRIMARY 
( NAME = N\'TestFileInit\', FILENAME = N\'F:\\DBBackup\\TestFileInit.mdf\' , SIZE = 41943040KB , FILEGROWTH = 1024KB )
 LOG ON 
( NAME = N\'TestFileInit_log\', FILENAME = N\'F:\\DBBackup\\TestFileInit_log.ldf\' , SIZE = 1024KB , FILEGROWTH = 10%)
GO

（Figure7：之前创建时间）

（Figure8：之后创建时间）

注意：禁用即时文件初始化功能，要想让这个禁用生效，一样需要重启SQL Server (MSSQLSERVER)服务。

五.疑问（Questions）

1. 在安装SQL Server的时候，如何设置会使得SQL Server服务是以【网络服务】登陆的？

2. 禁用掉SQL Server的协议Shared Memory，这个协议是用来干嘛的？有什么作用？

3. 如果把NT AUTHORITY\\NETWORKSERVICE加入到Windows组里面有什么不安全隐患嘛？

4. 当启用 TDE 时，即时文件初始化功能不可用。什么是TDE？

六.参考文献（References）

数据库文件初始化

为SQL Server 2005配置Windows即时初始化

Local System/Network Service/Local Service权限详解

SQL Server 索引中include的魅力（具有包含性列的索引）

开文之前首先要讲讲几个概念

　　【覆盖查询】

　　　　当索引包含查询引用的所有列时，它通常称为“覆盖查询”。

　　【索引覆盖】

　　　　如果返回的数据列就包含于索引的键值中，或者包含于索引的键值+聚集索引的键值中，那么就不会发生Bookup Lookup，因为找到索引项，就已经找到所需的数据了，没有必要再到数据行去找了。这种情况，叫做索引覆盖；

　　【复合索引】

　　　　和复合索引相对的就是单一索引了，就是索引只包含一个字段，所以复合索引就是包含两个或者多个字段的索引；

　　【非键列】

　　　　键列就是在索引中所包含的列，当然非键列就是该索引之外的列了；

下面就开始今天的主题

　　【摘要1】

　　在 SQL Server 2005 中，可以通过将非键列添加到非聚集索引的叶级别来扩展非聚集索引的功能。通过包含非键列，可以创建覆盖更多查询的非聚集索引。这是因为非键列具有下列优点：
* 它们可以是不允许作为索引键列的数据类型。
* 在计算索引键列数或索引键大小时，数据库引擎不考虑它们。
　　当查询中的所有列都作为键列或非键列包含在索引中时，带有包含性非键列的索引可以显著提高查询性能。这样可以实现性能提升，因为查询优化器可以在索引中找到所有列值；不访问表或聚集索引数据，从而减少磁盘 I/O 操作。

　　说明：第一：只能是针对非聚集索引；第二：比起复合索引是有性能上的提升的，因为索引的大小变小了；

　　【摘要2】

　　键列存储在索引的所有级别中，而非键列仅存储在叶级别中。

　　说明：这就表现为包含与不包含的关系了。有关索引级别的详细信息，请参阅表组织和索引组织。

　　【摘要3】

　　使用包含性列以避免大小限制
　　可以将非键列包含在非聚集索引中，以避免超过当前索引大小的限制（最大键列数为 16，最大索引键大小为 900 字节）。数据库引擎计算索引键列数或索引键大小时，不考虑非键列。
　　例如，假设要为 AdventureWorks 示例数据库的 Document 表中的以下列建立索引：
     Title nvarchar(50)
     Revision nchar(5)
     FileName nvarchar(400)
　　因为 nchar 和 nvarchar 数据类型的每个字符需要 2 个字节，所以包含这三列的索引将超出 900 字节的大小限制 10 个字节 (455 * 2)。使用 CREATE INDEX 语句的 INCLUDE 子句，可以将索引键定义为 (Title, Revision)，将 FileName 定义为非键列。这样，索引键大小将为 110 个字节 (55 * 2)，并且索引仍将包含所需的所有列。下面的语句就创建了这样的索引。

　　说明：当你把一个nvarchar(500)的字段设置为主键的时候，你就可以看到不能超出900字节的提示了。一般来说我们是不太会做这些操作的，所以那个错误提示也是不常见的，也许你可能还见过。

　　一个数据页的大小才8k，所以我们合理的设置每个字段的大小，不要浪费太多的空间，这样对查询也是有好处的，这个include就比较好的的解决了索引和空间的问题，虽然那些include的数据也会占用空间。

　　虽然可以设置include，但是也尽量不要使用太多的字段作为索引包含的非键列。

　　【摘要4】

　　带有包含性列的索引准则
　　设计带有包含性列的非聚集索引时，请考虑下列准则：
    * 在 CREATE INDEX 语句的 INCLUDE 子句中定义非键列。
    * 只能对表或索引视图的非聚集索引定义非键列。
    * 除 text、ntext 和 image 之外，允许所有数据类型。
    * 精确或不精确的确定性计算列都可以是包含性列。有关详细信息，请参阅为计算列创建索引。
    * 与键列一样，只要允许将计算列数据类型作为非键索引列，从 image、ntext 和 text 数据类型派生的计算列就可以作为非键（包含性）列。
    * 不能同时在 INCLUDE 列表和键列列表中指定列名。
    * INCLUDE 列表中的列名不能重复。

　　说明：include不能使用在聚集索引中。后面的两点，这个在实际中很难想象会有这样的需求要把重复列放到一个索引中。如果有朋友遇到过这样的需求可以告知一些，不胜感激。那如果有是否可以通过不同的列名（其实保存是同样的值）来解决这个问题呢？？

　　【摘要5】

　　列大小准则
    * 必须至少定义一个键列。最大非键列数为 1023 列。也就是最大的表列数减 1。
    * 索引键列（不包括非键）必须遵守现有索引大小的限制（最大键列数为 16，总索引键大小为 900 字节）。
    * 所有非键列的总大小只受 INCLUDE 子句中所指定列的大小限制；例如，varchar(max) 列限制为 2 GB。

　　说明：varchar(max)这样的定义是在2005之后才有的，所以这些数值也是对2005后的版本才生效的。

　　最大的表列数为：1024

　　最大非键列数为：1023

　　【摘要6】

　　修改已定义为包含性列的表列时，要受下列限制：
    * 除非先删除索引，否则无法从表中删除非键列。
    * 除进行下列更改外，不能对非键列进行其他更改：
          o 将列的为空性从 NOT NULL 改为 NULL。
          o 增加 varchar、nvarchar 或 varbinary 列的长度。
    * 这些列修改限制也适用于索引键列。

　　说明：这些细小的东西一直没有注意过。所以要记录下来，用来“防身”，呵呵。

　　【摘要7】

　　设计建议
　　重新设计索引键大小较大的非聚集索引，以便只有用于搜索和查找的列为键列。将覆盖查询的所有其他列设置为包含性非键列。这样，将具有覆盖查询所需的所有列，但索引键本身较小，而且效率高。

　　说明：也就是说把常用的where后面的条件查询的字段作为索引的键列，而需要返回的字段就作为索引包含的非键列。

　　如果where的是两个或两个以上的谓词的话，这个索引就可以创建为复合索引了。以前天真的认为要返回的字段只能通过在复合索引中入这些字段，不管它是否会用来做谓词。看到这篇文章，才有了豁然开朗的感觉。

　　【摘要8】

USE AdventureWorks;
GO
CREATE INDEX IX_Address_PostalCode
ON Person.Address (PostalCode)
INCLUDE (AddressLine1, AddressLine2, City, StateProvinceID);

　　说明：这个是使用include的语法，在表的设计中的索引设计中是没有办法选择的；

　　【摘要9】

　　性能注意事项
　　避免添加不必要的列。添加过多的索引列（键列或非键列）会对性能产生下列影响：
    * 一页上能容纳的索引行将更少。这样会使 I/O 增加并降低缓存效率。
    * 需要更多的磁盘空间来存储索引。特别是，将 varchar(max)、nvarchar(max)、varbinary(max) 或 xml 数据类型添加为非键索引列会显著增加磁盘空间要求。这是因为列值被复制到了索引叶级别。因此，它们既驻留在索引中，也驻留在基表中。
    * 索引维护可能会增加对基础表或索引视图执行修改、插入、更新或删除操作所需的时间。
　　您应该确定修改数据时在查询性能上的提升是否超过了对性能的影响，以及是否需要额外的磁盘空间要求。有关评估查询性能的详细信息，请参阅查询优化。

　　说明：“这是因为列值被复制到了索引叶级别”这句很好的说明了物理上的存储结构和原理。

　　【图片解析】

　　上图也说明了为什么不能在聚集索引中建立具有包含性列的索引，因为非聚集索引的叶层是由索引页而不是由数据页组成，这就得说到聚集和非聚集索引的的物理存储了，聚集索引的顺序排序和存储就是基表的顺序和存储结构。

　　【一个例子】

SELECT UserName,Password,RealName,Mobile,Age FROM bw_Users WHERE UserName = XXX AND Age = XX

说明：

这是一个我们很常见的查询语句，我们如何提高查询效率呢？
首先我们来看看谓词，这条语句是通过UserName = XXX AND Age = XX作为条件的，那么我们就应该建立一个组合索引，也称为复合索引，注意索引中的键列的位置，先UserName后Age；
其实上面那个是一个非聚集索引，那我们就可以把Password,RealName,Mobile这三列作为索引包含列；
所以，最终就是建立一个以UserName 和 Age做为键列、Password,RealName,Mobile作为非键列的非聚集索引；
通常来说我们系统的用户表并不是很大，所以这样的优化起不了很明显的效果，如果有兴趣的可以使用大表进行性能测试；