谈数据库的性能优化

时间 2019-12-09

标签数据库性能优化栏目 SQL 繁體版

原文原文链接

这篇文章是我花了不少时间写出来的，曾经发表在javaeye论坛上，今天竟然不见了，幸亏网上有人转载这篇文章，没办法，只好再一份在博客里。这个是我之前写给我部门的一个技术心得，鄙人才疏学浅，知道javaeye高人不少，若是我写的不对的地方，欢迎指教。 java

我靠这么多关键字过滤啊，“fapiao”也成了关键字mysql

1:前言sql

数据库优化是一个很广的范围,涉及到的东西比较多,而且每一个特定的数据库,其具体的优化过程也是不同的.由于优化的很大一部分最终都要跟具体的数据库系统细节打交道,在此不可能针对全部的数据库都一一详细阐述,若是那样,恐怕写几本书都写不完.只能针对一些比较通用的,常常用到的的东西进行一个讨论,一般状况下,数据库的优化指的就是查询性能的优化(虽然严格上来讲不该该是这样的),让数据库对查询的响应尽量的快.仅对数据库系统自己而言,影响到查询性能的因素从理论上来说，包括数据库参数设置(其实就是经过参数控制数据库系统的内存,i/o,缓存，备份等一些管理性的东西),索引,分区,sql语句.数据库参数设置自己是一个很复杂的东西，分区则主要是针对大数据量的状况下，它分散了数据文件的分布，减小磁盘竞争，使效率获得提高。数据库

每种数据库或多或少都有一些本身特定的索引,如oracle除了常规索引以外还有反向索引,位图索引,函数索引,应用程序域索引等等,可以让用户对数据的逻辑组织有着更为精确的控制,而sqlserver没有这么多的索引,大致来讲,sqlserver的索引分为两种:汇集索引和非汇集索引.在分区方面,oracle和sqlserver比较类似,不过sqlserver的分区更为繁琐一些,但随着sqlserver的版本愈来愈高,其分区操做也趋向于简洁.sql语句优化则基本上比较独立，目前的一些数据库系统处理sql的机制都比较相似，由于sql自己就是一个标准。这三种将会在下面做一个详细的讨论.本讨论创建在sqlserver上,由于目前部门的不少系统的数据库用到的是sqlserver,虽然oracle会给与咱们更多的可探讨的范围. api

2:测试数据库的创建
由于要讨论索引,分区,sql等,所以有必要创建一个数据库,否则只是泛泛而谈,我在sqlserver2000上创建了一个名为ipanel的数据库,该数据库只有一张表,名为person,person的定义以下:缓存

CREATE TABLE [dbo].[person] (
[id] [bigint] NOT NULL , --记录的id
[name] [varchar] (10) COLLATE Chinese_PRC_CI_AS NULL ,--姓名
[age] [int] NULL ,--年龄
[addr] [varchar] (50) COLLATE Chinese_PRC_CI_AS NULL ,--地址
[sex] [char] (10) COLLATE Chinese_PRC_CI_AS NULL ,--性别
[dept] [varchar] (50) COLLATE Chinese_PRC_CI_AS NULL ,--部门
[pos] [varchar] (50) COLLATE Chinese_PRC_CI_AS NULL ,--邮编
[tel] [char] (15) COLLATE Chinese_PRC_CI_AS NULL ,--电话
[fax] [char] (15) COLLATE Chinese_PRC_CI_AS NULL ,--传真
[emdate] [datetime] NULL --入职日期
) ON [PRIMARY]安全

ON[PRIMARY]表示该表建在系统的默认文件组上，在sqlserver里，文件组的概念就至关于oracle的表空间，是一种逻辑概念,它包含了数据文件，所谓数据文件，固然就是存储数据的文件.默认状况下，sqlserver会在默认的路径创建文件组和初始的数据文件，若是用户在创建数据库或表的时候没有指定文件组，则用默认的。数据文件,日志文件,参数文件是全部数据库系统最主要的文件,oracle还有控制文件,在不少的专业书籍里面,从数据库系统的物理结构上来说,数据库就是指的静态的数据文件,数据库系统或者数据库实例指的是一组进程,如日志进程,数据缓冲进程，网络监听进程等,这些进程做用在各类文件上面。不说了,扯远了.建了一个数据插入的存储过程: 服务器

CREATE PROCEDURE initPerson @start int, @end int , --起始条数，结束条数
@name varchar(10),@age int, --姓名，年龄
@addr varchar(10),@sex char(2), --地址，性别
@dept varchar(20),@emdate varchar(10 --部门，入职日期
AS
declare @id int
set @id=@start
while @id<=@end
begin
insert into person values(@id,@name,@age,@addr,@sex,@dept ,
'438200','82734664','82734665',@emdate)
set @id=@id+1
end
GO 网络

如下插入记录
exec initPerson 1,100000, ‘王**’,24,’深圳’,’男’,’应用开发部’,’2007-06-04’
插入10万条名叫王**的记录，由于在当前的例子中，姓名不重要，因此相同的姓名不碍事。以下依次执行
exec initPerson 100001,200000, ‘韩**’,25,’深圳’,’男’,’应用工程部’,’2007-06-05’
exec initPerson 200001,300000, ‘徐*’,26,’ 深圳’,’男’,’系统终端部’,’2007-06-06’
exec initPerson 300001,500000, ‘程*’,23’, 深圳’,’男’,’研发中心’,’2007-06-07’
exec initPerson 500001,750000, ‘卓*’,22,’ 深圳’,’男’,’行政部’,’2007-06-08’
exec initPerson 750001,1000000, ‘流*’,20,’ 深圳’,’男’,’业务合做部’,’2007-06-09’
接着依次插入相似的记录,我就不一一列举了.
执行完毕，person表便有了200万条记录。为何我不用更多的数据呢,由于我要频繁的改变数据库的设置,若是数据很是多,那当我改变数据库设置时候, 会耗费很长的时间,好比索引更新维护等,不太方便.值得一提的是，若是没有指定汇集索引，那么sqlserver默认在主键上创建汇集索引，在当前状况下，系统在id列上创建了汇集索引。
数据库创建完毕,下面将会对索引,分区,sql作比较详细的讨论架构

3:索引

索引是各类关系数据库系统最多见的一种逻辑单元,是关系数据库系统举足轻重的重要组成部分,对于提升检索数据速度有着相当重要的做用,索引的原理是根据索引值获得行指针,而后快速定位到数据库记录..

3.1:常见索引介绍

1: B*树索引
这是最多见的索引,几乎全部的关系型数据库系统都支持B*树结构的索引,也是被最多使用的,其树结构与二叉树比较相似,根据行id快速定位到行.大部分数据库默认创建的索引就是这种索引.B*树索引在检索高基数数据列(高基数列是指该列有不少不一样的值,该列全部不一样值的个数之和与该列全部值的个数之和的比成为列基数)时提供了比较好的性能,B*树索引是基于二叉树的,由分支块和叶块组成.在树结构中,位于最底层的快成为叶块,包含每一个被索引列的值和行所对应的rowid.在叶节点的上面是分支块,用来导航结构,包含了索引列(关键字)范围和另外一索引快的地址,如图所示: （图片插入作的不够好，插图进来我以为很好麻烦）

假设要查找索引中值为80的行，从索引树的最上层入口开始，首先定位到大于等于50，而后往左找，找到第二个分支块，定位到75―100，而后定位到叶块，定位到叶块，找到80所对应的rowid，而后根据rowid到数据块读取对应的数据。若是查询条件是范围选择的，好比colume>20 and colume<80,那么会先定位到20的块，而后再横向查找到80的块为止，不是每次都从入口进去从新定位的。
要说明的是, 这种索引是用得最多的,基本上全部的数据库系统都支持这种索引,它是索引里最主要最广泛的,它之因此称为B*树索引,更可能是由于它的存储结构有着广泛的意义,不少索引都基于这种结构,固然sqlserver里没有名为B*树的索引,可是不妨碍咱们以对B*树索引的认识去理解sqlserver的索引,不是吗?这是我为何把它放在最前面的缘由.

2:汇集索引

没错,这是sqlserver里很重要的一个索引.也叫群集索引。汇集索引是相对于常规索引而言的,oracle也有相似的索引,不过叫聚簇索引,注意,虽然聚簇和汇集仅有一字之差,可是oracle的聚簇索引和 sqlserver的汇集索引仍是有不少的不一样的,oracle的聚簇索引能够针对多表,根据多个表相同列的不一样值,将相关数据汇集在周围.sqlserver汇集索引也有相似的意思,可是只能针对单表.在oracle里,聚簇”是oralce内部的一个对象,就像基本表,视图,触发器这些概念同样. 聚簇索引就是对聚簇进行的索引,因为比较复杂,在此不详细讨论,但在sqlserver里,汇集索引直接做用在表上,所以不能够将两者混淆.反正不能等同来看就是了.

举个例子说明来讲明sqlserver的汇集索引:咱们的汉语字典的正文自己就是一个汇集索引。好比，咱们要查“安”字，就会很天然地翻开字典的前几页，由于“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就天然地排在字典的前部。若是您翻完了全部以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；一样的，若是查“张”字，那您也会将您的字典翻到最后部分，由于“张”的拼音是 “zhang”。也就是说，字典的正文部分自己就是一个目录，您不须要再去查其余目录来找到您须要找的内容。咱们把这种正文内容自己就是一种按照必定规则排列的目录称为“汇集索引”。汇集索引都是排好序的.

若是您认识某个字，您能够快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而须要去根据“偏旁部首”查到您要找的字，而后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并非真正的正文的排序方法，好比您查“张”字，咱们能够看到在查部首以后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码倒是63 页，“张”的下面是“弩”字，页面是390页。很显然，这些字并非真正的分别位于“张”字的上下方，如今您看到的连续的“驰、张、弩”三字实际上就是他们在非汇集索引中的排序，是字典正文中的字在非汇集索引中的映射。咱们能够经过这种方式来找到您所须要的字，但它须要两个过程，先找到目录中的结果，而后再翻到您所须要的页码。
总而言之, 汇集索引就是使与被索引的值相关的行数据块集中在一块儿,不是物理上的散列分布.这样,首先缩小了扫描范围,并且定位数据的时间短,能够想象一下查字典的时候,根据拼音查找汉字,找以”a”发音开头的字,你只会在a字母里面找,若是a字母找完了,那么无论有没有这个字,查找过程也就结束了。
非汇集索引也是B*树结构，只不过每一个索引值对应的不是行id，而是数据行自己，汇集索引会对表排序，就像字典同样，它按照英文字母的顺序排序的，因此在基于某个范围搜索的时候，它的查询效率是很高的，但同时咱们也能够看到，它占据了更多的空间，在插入更新的时候，它会花多一点的时间维持本身的索引顺序。每一个表只能有一个汇集索引，这是固然的，由于每一个表确定只可能有一个全表排序的规则。

3:非汇集索引
非汇集索引是一种典型的B*树索引,每一个叶块只包含两种数据,一种是索引项,一种是该索引项所在行的行指针,当查询的数据匹配该索引项数据的时候,将会取出对应的行指针,取得该行的数据.若是要根据键值从大型 SQL Server 表提取具备良好选择性的少数几行，非汇集索引最有用。B*树的底部或叶级包含组成该索引的列中的全部数据。当用非汇集索引检索表中与键值匹配的信息时，将搜索整个索引 B 树，直到在索引叶级找到一个与键值匹配的值。
在非汇集索引中，叶级节点仅包含参与索引的数据以及快速找到相关数据页上其它行数据的指针。最糟糕的状况是，从非汇集索引中得到的每一行都要求一个额外的不连续磁盘 I/O 才能检索行数据。最好的状况是，所须要的行有许多都位于相同的数据页，所以在提取每一个数据页时可检索多行。若是是汇集索引，索引的叶级节点是表的实际数据行。所以，检索表数据时不须要指针跳动。基于汇集索引的范围扫描执行状况很好，由于汇集索引的叶级（即表的全部行）在物理上按照组成汇集索引的列顺序排列在磁盘上.

4:覆盖索引
覆盖索引是非汇集索引的一个特例。覆盖索引的定义是在选择条件和 WHERE 谓词上均知足 SQL 查询的全部列的基础上创建的非汇集索引。覆盖索引能够节省大量的 I/O，所以可极大地改善查询的性能。可是有必要在新建索引（以及与它相关的 B 树索引结构维护）所须要的代价和覆盖索引所带来的 I/O 性能增益之间进行权衡。若是覆盖索引对于 SQL Server 上常常运行的查询或查询组极其有利，那么建立覆盖索引是值得的。
覆盖索引的示例

Select col1,col3 from table1 where col2 = 'value'.
Create index indexname1 on table1(col2,col1,col3).
本例中建立出来的索引“indexname1”是一个覆盖索引，由于它包括 SELECT 语句和 WHERE 谓词中的全部列。即在执行此查询期间，SQL Server 不须要访问与 table1 相关的数据页。SQL Server 使用索引 indexname1 能够得到知足查询所须要的所有信息。在 SQL Server 已遍历与 indexname1 相关的 B 树，并找到 col2 等于“value”的索引关键字范围，SQL Server 就知道它能够从覆盖索引的叶级（底层）提取全部须要的数据 (col1,col2,col3)。这从两个方面改进了 I/O 性能：

SQL Server 仅从索引页而不是数据页获取全部须要的数据，所以数据的压缩率更高，使 SQL Server 能够节省磁盘 I/O 操做。
覆盖索引按照 col2 将全部须要的数据以物理方式组织在磁盘上。使硬盘得以连续返回与 where 谓词 (col2 = "value") 相关的全部索引行。从而为咱们提供了更好的 I/O 性能。总而言之，若是覆盖索引中的全部列的字节数比该表中单行的字节数少，而且能够确定将反复执行使用此覆盖索引的查询，那么使用覆盖索引是有意义的。

5:位图索引
这个不是sqlserver的索引，它是oracle的，因此请不要混淆。之因此提出来，是由于它不是B*树结构的索引。位图索引相对于B*tree索引来讲,它的存储结构是不同的,一般在B*tree索引中,在索引条目和行之间有一对一的关系.对于位图索引,一个索引条目使用一个位图同时指向许多行. 这对于基本上只读的低基数(数据只有不多的几个大相径庭的值)数据是合适的.好比说,一个person表,有个性别字段sex,Y表明男,N表明女,对于有几百万行数据的表来讲, 位图索引是一个很是好的选择。它能够迅速的扫描出来，而不用象对B*树索引那样的查找。

3.2 有效的利用索引

索引在数据库的查询优化中起着相当重要的做用，一个数据库索引的好与坏，其查询性能相差不少倍，下面将谈一下各类索引的使用场合和一些观点。如何选择索引可显著影响所产生的磁盘 I/O，并于是影响查询性能。在非汇集索引中，选择性很重要，由于若是在只有少许惟一值的大型表上建立非汇集索引，使用非汇集索引将不会节省数据检索中的 I/O。由于B*树结构的索引都注重一种比较性，这样它能够快速的肯定范围，定位位置,例如，person表的性别字段，非男即女，不具备可比性，若是以它为非汇集索引，查询的时候也只能一个个叶节点去比较。在这种状况下产生的 I/O 可能比对表进行连续扫描所产生的 I/O 多得多。比较适合非汇集索引的有票据编号、惟一的客户编号、社会安全号码和电话号码，简单来讲，就是基于某种可比较的，有规律的数据。
建立汇集索引以前，应先了解数据是如何被访问的。

考虑对具备如下特色的查询使用汇集索引：

使用运算符（如 BETWEEN、>、>=、< 和 <=）返回一系列值。使用汇集索引找到包含第一个值的行后，即可以确保包含后续索引值的行物理相邻。例如，若是某个查询在一系列销售订单号间检索记录，销售单号列的汇集索引可快速定位包含起始销售订单号的行，而后检索表中全部连续的行，直到检索到最后的销售订单号。
返回大型结果集。
使用 JOIN 子句；通常状况下，使用该子句的是外键列。
使用 ORDER BY 或 GROUP BY 子句。
在 ORDER BY 或 GROUP BY 子句中指定的列的索引，可使数据库引擎没必要对数据进行排序，由于这些行已经排序，这样能够提升数据库性能

通常状况下，定义汇集索引键时使用的列越少越好。考虑具备下列一个或多个属性的列：

惟一或包含许多不重复的值
例如，雇员 ID 惟一地标识雇员。EmployeeID 列的汇集索引或 PRIMARY KEY 约束将改善基于雇员 ID 号搜索雇员信息的查询的性能。另外，可对 LastName、FirstName、MiddleName 列建立汇集索引，由于常常以这种方式分组和查询雇员记录，并且这些列的组合还可提供高区分度。

按顺序被访问
例如，id惟一地标识person表中的记录，在其中指定顺序搜索的查询（如 WHERE ID BETWEEN 1000 and 2000）将从id的汇集索引受益。这是由于行将按该键列的排序顺序存储。

常常用于对表中检索到的数据进行排序。
按该列对表进行汇集（即物理排序）是一个好方法，它能够在每次查询该列时节省排序操做的成本。
汇集索引不适用于具备下列属性的列：

频繁更改的列
这将致使整行移动，由于数据库引擎必须按物理顺序保留行中的数据值。这一点要特别注意，由于在大容量事务处理系统中数据一般是可变的。

宽键
宽键是若干列或若干大型列的组合。全部非汇集索引将汇集索引中的键值用做查找键。为同一表定义的任何非汇集索引都将增大许多，这是由于非汇集索引项包含汇集键，同时也包含为此非汇集索引定义的键列。

3.3 谈索引使用的误区

理论的目的是应用。虽然咱们刚才列出了什么时候应使用汇集索引或非汇集索引，但在实践中以上规则却很容易被忽视或不能根据实际状况进行综合分析。下面咱们将根据在实践中遇到的实际问题来谈一下索引使用的误区。

1:主键就是汇集索引
这种想法我认为不是太合理，大多数状况下，主键上的汇集索引是对汇集索引的一种浪费。虽然SQL SERVER默认是在主键上创建汇集索引的。一般，咱们会在每一个表中都创建一个ID列，以区分每条数据，而且这个ID列是自动增大的，步长通常为1。此时，若是咱们将这个列设为主键，SQL SERVER会将此列默认为汇集索引。这样作有好处，就是可让您的数据在数据库中按照ID进行物理排序，但我认为这样作意义不大。由于在不少状况下，由于主键的惟一性，对id或者主键进行范围扫描是比较少的。显而易见，汇集索引的优点是很明显的，而每一个表中只能有一个汇集索引的规则，这使得汇集索引变得更加珍贵。从咱们前面谈到的汇集索引的定义咱们能够看出，使用汇集索引的最大好处就是可以根据查询要求，迅速缩小查询范围，避免全表扫描。
在实际应用中，由于ID号是自动生成的，咱们并不知道每条记录的ID号，因此咱们很难在实践中用ID号来进行查询。这就使让ID号这个主键做为汇集索引成为一种资源浪费。其次，让每一个ID号都不一样的字段做为汇集索引也不符合“大数目的不一样值状况下不该创建聚合索引”规则；固然，这种状况只是针对用户常常修改记录内容，特别是索引项的时候会负做用，但对于查询速度并无影响。若是您的汇集索引盲目地建在ID这个主键上时，查询速度不必定会提升的，即便你在其余字段上创建非汇集索引。下面咱们就来看一下在200万条数据量的状况下各类查询的速度表现：

（1）全表扫描
 只在主键上创建汇集索引：
Select id,name,dept,emdate from person
用时：20546毫秒（即：21秒）
 不在主键上创建汇集索引，只建普通索引
Select id,name,dept,emdate from person
用时：17923毫秒（即：18秒）
以上查询执行的实际上索引不会发挥做用，由于提取的是所有数据。汇集索引在这里会耗费更多的资源，因此会看到，不创建汇集索引比创建汇集索引还要快

(2):按日期进行过滤(用到索引)
 在主键上创建汇集索引，在emdate上创建非汇集索引：
select id,name,dept,emdate from person where emdate>dateadd(day,+1,getdate())
用时：12376毫秒（12秒）

 在主键上创建汇集索引，在emdate上没有索引：
select id,name,dept,emdate from person where emdate>dateadd(day,+1,getdate())
用时：21296毫秒（21秒）

 在主键上创建非汇集索引，在emdate上创建非汇集索引：
select id,name,dept,emdate from person where emdate>dateadd(day,+1,getdate())
用时：11590毫秒（12秒）

 在主键上创建非汇集索引，在emdate上创建汇集索引：
select id,name,dept,emdate from person where emdate>dateadd(day,+1,getdate())
andemdate<dateadd(day,+3,getdate())
用时：5233毫秒（5秒）

虽然每条语句提取出来的都是30万条数据，各类状况的差别倒是比较大的，特别是将汇集索引创建在日期列时的差别。事实上，若是您的数据库真的有几千万条记录的话，差距会更明显。

2:只要创建索引就能显著提升查询速度
这个想法是错误的。事实上，咱们能够发现上面的例子中，上面按日期过滤的语句彻底相同，且创建索引的字段也相同，但查询速度却有着很是大的差异。因此，并非是在任何字段上简单地创建索引就能提升查询速度。索引的创建，会带来更多的系统开销，由于系统要耗费资源去维护它，若是创建了没有用到的索引，不适当的索引，过多的索引，反而会致使查询性能降低。总之索引的创建，要看表的结构，数据的分布，还有你要用到哪些数据，如果把索引创建在你根本不须要的数据列上，是根本不会发挥做用的。

3:把全部须要提升查询速度的字段都加进汇集索引，以提升查询速度
这个不必定正确。上面已经谈到。假设如今查询要用到用户名和日期这两个字段，咱们能够把他们合并起来，创建一个复合索引（compound index）。不少人认为只要把任何字段加进汇集索引，就能提升查询速度，也有人感到迷惑：若是把复合的汇集索引字段分开查询，那么查询速度会减慢吗？带着这个问题，我们来看一下如下的查询速度（结果集都是25万条）：（日期列emdate首先排在复合汇集索引的起始列，用户名name排在后列）

 select id,name,dept,emdate from person where emdate>'2007-06-01'
查询速度：1664毫秒
 select id,name,dept,emdate from person
where emdate>'2007-06-01' and name=’王小雪’
查询速度：1640毫秒
 select gid,fariqi,neibuyonghu,title from person
where name='王小雪'
查询速度：5920毫秒
从以上试验中，咱们能够看到若是仅用汇集索引的起始列做为查询条件和同时用到复合汇集索引的所有列的查询速度是几乎同样的，而若是仅用复合汇集索引的非起始列做为查询条件的话，这个索引是不起任何做用的。固然，语句一、2的查询速度同样是由于查询的条目数同样，若是复合索引的全部列都用上，并且查询结果少的话，这样就会造成“索引覆盖”，于是性能能够达到最优。同时，请记住：不管您是否常用聚合索引的其余列，但其前导列必定要是使用最频繁的列。

3.4 其余索引经验总结
1:用聚合索引比用不是聚合索引的主键速度快
下面是实例语句：（都是提取25万条数据）
select id,name,dept,emdate from person where emdate='2007-06-04'
使用时间：906毫秒

select id,name,dept,emdate from person where id<=100000
使用时间：1153毫秒
这里，用聚合索引比用不是聚合索引的主键速度略快一些。

2:用聚合索引比用通常的主键做order by时速度快，特别是小数据量时
select id,name,dept,emdate from person order by emdate
用时：17856 (约18秒)

select id,name,dept,emdate from person order by id
用时：44046 (约45秒)

这里能够看到，用汇集索引比用通常的主键做order by时，速度几乎快了2.5倍。事实上，有的资料说小数据量状况下，用汇集索引排序列比非汇集索引做为排序列快，10万以上，则两者的速度差异不明显。但据当前200万条数据状况来看，在大数据量的状况下，这个结论依然成立。

3:使用聚合索引内的时间段，搜索时间会按数据占整个数据表的百分比
比例减小，而不管聚合索引使用了多少个
select id,name,dept,emdate from person where
emdate='2007-06-04 00:00:00.000'
用时：1123毫秒（提取10万条）

select id,name,dept,emdate from person where
emdate='2007-06-04 00:00:00.000'
用时：1843毫秒（提取20万条）

select id,name,dept,emdate from person where
emdate='2007-06-09 00:00:00.000'
用时：4500毫秒（提取45万条）

从以上统计的数据看来，这个规律基本上是正确的

其余注意事项
“水可载舟，亦可覆舟”，索引也同样。索引有助于提升检索性能，但过多或不当的索引也会致使系统低效。由于用户在表中每加进一个索引，数据库就要作更多的工做。过多的索引甚至会致使索引碎片。因此说，咱们要创建一个“适当”的索引体系，特别是对聚合索引的建立，更应精益求精，以使您的数据库能获得高性能的发挥。在实际的开发中，会遇到不少意想不到的状况，最好是多测试一些方案，找出哪一种方案效率最高、最为有效。

4:SQL语句改善
一个sql语句大约要通过三个阶段，编译优化，执行，取值，而编译阶段，而第一阶段大部分状况下都要花掉60％的时间，因此绑定变量是很重要的，sqlserver和oracle都有缓存区，存放最近使用的sql语句，当有一条sql语句到达数据库服务器时，数据库会首先搜索缓存区，看它是否存在能够重用的sql语句，若是存在，则无需编译优化，由于缓存区的sql语句都是编译优化好了的，能够直接执行，节省至关多的时间。若是没有发现该语句，则必需要彻底经历语句编译分析，优化计划，安全检查等过程，这不只耗费了大量的cpu功率，并且还在至关长的一段时间内锁住了一部分数据库缓存，这样执行sql语句的人越多，等待的时间越长，系统的性能会大幅度的降低。

不少人不知道SQL语句在SQL SERVER中是如何执行的，他们担忧本身所写的SQL语句会被SQL SERVER误解。好比：
select id,name,dept,emdate from person
where name='王小雪' and id<100000 用时：1220毫秒
和执行:
select * from table1 where id< 100000 and name='王小雪' 用时：1173毫秒
一些人不知道以上两条语句的执行效率是否同样，由于若是简单的从语句前后上看，这两个语句的确是不同，若是id是一个聚合索引，那么后一句仅仅从表的 100000条之内的记录中查找就好了；而前一句则要先从全表中查找看有几个name='王小雪'的，然后再根据限制条件条件id<100000来提出查询结果。事实上，这样的担忧是没必要要的。SQL SERVER中有一个“查询分析优化器”，它能够计算出where子句中的搜索条件并肯定哪一个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。

虽然查询优化器能够根据where子句自动的进行查询优化，但你们仍然有必要了解一下“查询优化器”的工做原理，如非这样，有时查询优化器就会不按照您的本意进行快速查询。在查询分析阶段，查询优化器查看查询的每一个阶段并决定限制须要扫描的数据量是否有用。若是一个阶段能够被用做一个扫描参数（SARG），那么就称之为可优化的，而且能够利用索引快速得到所需数据。 SARG的定义：用于限制搜索的一个操做，由于它一般是指一个特定的匹配，一个值得范围内的匹配或者两个以上条件的AND链接。形式以下：
列名操做符 <常数或变量> 或 <常数或变量> 操做符列名
列名能够出如今操做符的一边，而常数或变量出如今操做符的另外一边。如：
Name=’张三’ ，价格>5000 ，5000<价格，Name=’张三’ and 价格>5000
若是一个表达式不能知足SARG的形式，那它就没法限制搜索的范围了，也就是SQL SERVER必须对每一行都判断它是否知足WHERE子句中的全部条件。因此一个索引对于不知足SARG形式的表达式来讲是无用的。
介绍完SARG后，咱们来总结一下使用SARG以及在实践中遇到的和某些资料上结论不一样的经验：

1:Like语句是否属于SARG取决于所使用的通配符的类型
如：name like ‘王%’ ，这就属于SARG
而：name like ‘%小雪’,就不属于SARG。
缘由是通配符%在字符串的开通使得索引没法使用。如如下查询
没有对name进行索引
select id,name,dept,emdate from person where name like '%小雪'
用时 3654毫秒
对name进行非汇集索引
select id,name,dept,emdate from person where name like '%小雪'
用时 3673毫秒
对name进行汇集索引
select id,name,dept,emdate from person where name like '%小雪'
用时 3673毫秒
由以上数据能够看到，将匹配符号放在被查询字段的前面，索引根本就不会发生做用，因此这也是要注意的地方，若是不会用到，最好少用

2:or 是否会引发全表扫描
有不少资料上说or会引发全表扫描。
如name=’王小雪’ and emdate>’2007-01-10’不会全表扫描,而
name=’ 王小雪’ or emdate>’2007-01-10’则会,可是据我观察,状况不是这样的.对于这样的一个sql语句select id,name,dept,emdate from person where name='王小雪' or emdate>'2007-06-08'，咱们能够看sqlserver对于它们的执行计划

在有汇集索引的状况下(不管汇集索引建在哪些字段上)

没有汇集索引可是主键索引的状况下

没有任何索引的状况下

由上能够得出结论,在用到or的时候，若是有汇集索引,就不会引发全表扫描,没有汇集索引,就会引发全表扫描，因此说，只要用or就会引发全表扫描是片面的，不正确的。

3:非操做符、函数引发的不知足SARG形式的语句

不知足SARG形式的语句最典型的状况就是包括非操做符的语句，如：NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等，另外还有函数。下面就是几个不知足SARG形式的例子：
ABS(价格)<5000 ,Name like ‘%三’ ，有些表达式，如： WHERE 价格*2>5000 ,SQL SERVER也会认为是SARG，SQL SERVER会将此式转化为： WHERE 价格>2500/2 .但不推荐这样使用，由于有时SQL SERVER不能保证这种转化与原始表达式是彻底等价的。

4:IN 的做用是否至关与OR
看下面的查询状况。
有汇集索引
select id,name,dept,emdate from person where name in('王小雪','聂海')
所花时间:8936ms,
select id,name,dept,emdate from person where name='王小雪' or name='聂海'
所花时间:5390ms,

没有汇集索引
select id,name,dept,emdate from person where name in('王小雪','聂海')
所花时间:5310ms,
select id,name,dept,emdate from person where name='王小雪' or name='聂海'
所花时间:5326ms,

可见,or 比 in速度快,由于做了汇集索引,因此它们都没有执行table scan,不过由于汇集索引做用在日期字段emdate上,因此虽然查询使用了汇集索引,但并不意味着比全表扫描快,其实使用做用在emdate上的汇集索引查询,在某种意义上来讲,也是一种全表扫描,只不过数据的扫描顺序不一样而已,在这种状况下,甚至没有汇集索引反而更快

5:exists 和 in 的执行效率是同样的
不少资料上都显示说，exists要比in的执行效率要高，同时应尽量的用not exists来代替not in。但事实上，我试验了一下，发现两者不管是前面带不带not，两者之间的执行效率都是同样的。由于涉及子查询，我试验此次用SQL SERVER自带的pubs数据库。运行前咱们能够把SQL SERVER的statistics I/O状态打开。语法为:set statistics io on, 要查看语句的执行过程,打开查询分析器的消息栏就能够看到,可是在查询语句以前要加上set statistics io on
（1）select title,price from titles where title_id in (select title_id from sales where qty>30)
该句的执行结果为：
表 'sales'。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。
表 'titles'。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。

（2）select title,price from titles where exists (select * from sales where sales.title_id=titles.title_id and qty>30)
第二句的执行结果为：
表 'sales'。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。
表 'titles'。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。

咱们今后能够看到用exists和用in的执行效率是同样的。

6:用函数charindex()和前面加通配符%的LIKE执行效率同样
前面，咱们谈到，若是在LIKE前面加上通配符%，那么将会引发全表扫描，因此其执行效率是低下的。但有的资料介绍说，用函数charindex()来代替LIKE速度会有大的提高，但据我测试，发现这种说明也是错误的：
select id,name,dept,emdate from person where charindex('小雪',name)>0
用时：4010ms
扫描计数 1，逻辑读 29905 次，物理读 0 次，预读 0 次。

select id,name,dept,emdate from person where name like '%小雪'
用时：4123ms
扫描计数 1，逻辑读 29905 次，物理读 0 次，预读 0 次。

7:union并不绝对比or的执行效率高
不少资料都推荐用union来代替or。事实证实，这种说法对于大部分都是适用的。
(1):select id,name,dept,emdate from person where name='王小雪' or emdate>'2007-06-04'
用时：85626ms。扫描计数 1，逻辑读 129905 次，物理读 0 次，预读 0 次。次。
(2):select id,name,dept,emdate from person where name='王小雪'
union
select id,name,dept,emdate from person where emdate>'2007-06-04'
用时：17373ms。扫描计数 2，逻辑读 59810 次，物理读 0 次，预读 0 次。
看来，用union在一般状况下比用or的效率要高的多。

5:sqlserver的分区
对于一些超大型的表，分区是很是有用的。分区是一种逻辑概念，和oracle的分区概念是同样的.在一般状况下，一个表就是一个总体，当发生数据访问的时候，也是对整个表或整个表的索引进行访问，所谓分区，通俗点讲，就是把表按必定的规律划分红更小的逻辑单位,当发生访问的时候,不以表为单位进行访问,而先在表的基础上,判断数据在哪一个分区,而后对特定的分区进行访问.正确的分区有利于提升查询性能.例如,有一个很是大的表,存储了一些销售记录,如今查询老是按销售季度来执行这个查询----每一个销售季度包含几十万个记录,一般你只是要查询这个数据集的一个至关小的数据,可是给予销售季度的检索却的确是不太可行的.这个索引可能指向无数个记录,而以这种方式执行索引范围扫描是可怕的.为了处理许多查询任务,系统须要执行全表扫描,可是结果却必须扫描几百万个记录,其中绝大部分不使用咱们的查询任务.使用智能分区方案,就能够按季度隔离数据.这样当咱们为任意指定的季度去查询数据时,结果将只是扫描那个季度的数据.这是全部可能的解决方案种最好的方案.下面将介绍sqlserver的分区使用.

分区是比较复杂的，以分区的对象来分类的话，则分为两种，表分区和索引分区。
表分区主要指的是范围分区，(貌似比较单一，oracle里有散列分区等等，不过在sqlserver里我目前尚未看到).就这么说可能不清不楚，下面将以咱们已经创建好的ipanel数据库为例，对person表进行按日期分区，假设ipanel每月都要进出几十万人，而后HR每个月还要做不少的统计吧。下面一步一步来，common

建立文件组
各类数据最终是存储在数据文件里，在实际应用中，表的分区都会分布在多个数据文件中，这样以便得到更好的 I/O 平衡，对于文件，是以文件组为单位进行管理，文件组至关于目录，数据文件就至关于目录里的文件。为数据库添加文件组，这个文件组分布存储person表的数据：
ALTER DATABASE ipanel ADD FILEGROUP [person_fg]
如今为ipanel数据库建立了一个名为person_fg的文件组。下面为该文件组添加数据文件。

添加数据文件
ALTER DATABASE ipanel
ADD FILE
(NAME = N'person001',
FILENAME = N'C:\ipanel\person001.ndf',
SIZE = 5MB,
MAXSIZE = 100MB,
FILEGROWTH = 5MB)
TO FILEGROUP [person_fg]
如上，为文件组添加了一个数据文件

建立分区函数
既然分区，那么就应该有一个分区的标准，就是说数据将以什么标准来分区，分区函数就是作这件事情的，它定义数据划分的标准，对表进行逻辑上的划分。
CREATE PARTITION FUNCTION personRangePFN(datetime)
AS
RANGE LEFT FOR VALUES ('20030930',
'20050930',
'20070930',
'20090930')
上面的分区函数建立了5个分区，而且定义了分区列的数据类型为datetime,由于分区的标准要建在表的某一列上，在此定义，分区列必须是日期时间型。 RANGE LEFT表示范围分区，LEFT所在的选项有两个：LEFT,RIGHT.分区标识着数据的上界和下界。如当前选项是LEFT，则表示：
分区1：<=20030930
分区2：>20030930,<=20050930
分区3：>20050930,<=20070930
分区4：>20070930,<=20090930
分区5：>20030930
若是当前选项是RIGHT,则表示：
分区1：<20030930
分区2：>=20030930,<20050930
分区3：>=20050930,<20070930
分区4：>=20070930,<20090930
分区5：>=20030930

建立分区架构
建立分区函数后，必须将其与分区架构相关联，以便将分区定向至特定的文件组。定义分区架构时，即便多个分区位于同一个文件组中，也必须为每一个分区指定一个文件组。对于前面建立的范围分区 (personRangePFN)，存在五个分区；最后一个空分区将在 PRIMARY 文件组中建立。由于此分区永远不包含数据，因此不须要指定特殊的位置
CREATE PARTITION SCHEME PersonEmdateScheme
AS
PARTITION personRangePFN
TO ([person001], [person002], [person003], [person004], [PRIMARY])

建立分区表
定义分区函数（逻辑结构）和分区架构（物理结构）后，便可建立表来利用它们。表定义应使用的架构，而架构又定义函数。要将这三者结合起来，必须指定应该应用分区函数的列。范围分区始终只映射到表中的一列，此列应与分区函数中定义的边界条件的数据类型相匹配。另外，若是表应明确限制数据集（而不是从负无穷大到正无穷大），则还应添加 CHECK 约束。

[emdate] [datetime] NULL
CONSTRAINT personRangeYear
CHECK ([emdate] >= '20020901'
AND [emdate] <= '20100901 11:59:59.997')

分区总结
到此，对于分区表person已经设置完毕，person的数据会根据emdate的值分布到几个不一样的数据文件里，在查询的时候，系统会首先判断 emdate的值，看它在哪一个分区，而后只进入该分区查找数据，这对于超大规模的系统来讲，是颇有用的，若是一个表有几千万上亿的数据，即便是索引扫描也是一个很费时的过程，不要忘记，索引也就像至关于简化了的表。对于索引，sqlserver里有索引分区，若是索引分区和表分区对齐的话，就是说和表同样使用了相同的分区函数和相同的分区架构，那么对于索引的查找，就不是对整个索引的查找了，而是先判断在哪一个索引分区，而后再取查找该索引值，而后找到数据，这样就会节省不少时间。分区还有一个好处就是，对于一些数据能够更好的进行管理，好比说，定义了2006年度的销售数据存储在对应的分区area6，而area6对应的数据文件是sale006.ndf,到2007年的时候，通常状况下，可能不用06年的数据，按照分区的理论，它也不会访问06年的数据所在的区域。
分区的应用是比较复杂的，上面只是介绍了其中一部分，其余还有索引分区，分区合并，分区移出等比较多的的东西。在oracle 里，分区的概念是比较多的，包括对索引的分区都会有不少介绍，如散列分区，混合分区，局部索引，全局索引，原理上是差很少的。在此谈分区只是一个抛砖引玉的过程，若是对sqlserver分区想更深刻了解的话，能够看看msdn，有中文的，不过翻译得很烂。

6:后记
我之前看到过不少项目，数据库系统只是被纯粹的看成了一个存储数据的地方，建完表能增删改查就万事大吉了，有的连索引都没有，对于数据库的创建也很不严谨，更谈不上管理，虽然不少人认为数据库的管理是DBA的事情，可是我想做为一个技术人员，加深对数据库的了解是绝对没有坏处的，开发大型的系统，数据库确定是很是重要的。若是想深刻学习一门数据库的话，我建议你们从oracle开始学，由于sqlserver做了不少封装，而oracle更为复杂，是的，虽然它概念不少，比较复杂，可是却有助你了解更多的数据库细节，在不少方面，大部分的数据库系统都是相同的，oracle学好再来学其余的数据库，上手就很是容易，若是你会写PL/SQL程序，那有什么理由不会写TRANACT-SQL的数据库程序呢，语法只是一些细微的差异，而不少的概念倒是相同的。

其余方法:

1．原则上为建立的每一个表都创建一个主键,主键惟一标识某一行记录，用于强制表的实体完整性。
2．为每个外键列创建一个索引，若是确认它是惟一的，就创建惟一索引。
3．暂时不要为其余列创建索引
4．当在TSQL中引用对象时，建议使用对象的架构名称限定。
5．使用SET NOCOUNT ON在每一个存储过程的开头SET NOCOUNT OFF在结尾
6.慎用锁，可使用NOLOCK提示，它与READUNCOMMITTED是等价的。更简单的作法是在存储过程的开头SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED，结尾READ COMMITTED。
7．查询仅仅返回须要的行和列
8．在适当的时候使用事务，尽可能将事务放在一个存储过程当中。9．尽可能少的使用临时表，由于大量使用临时表可能使tempdb成为瓶颈。可使用表表达式，包括派生表、CTE、视图和内联表值UDF。
10．避免使用NOT IN，能够用LEFT OUTER JOIN代替它
11．尽可能避免大事务操做，慎用holdlock子句，提升系统并发能力。、
12．尽可能避免反复访问同一张或几张表，尤为是数据量较大的表，能够考虑先根据条件提取数据到临时表中，而后再作链接。
13.不要在where子句中进行函数、算术运算或其余表达式运算，不然系统将可能没法正确使用索引。
14.尽可能使用exists代替select count(*)来判断是否存在记录
15.避免频繁建立和删除临时表，减小系统表资源的消耗。 1．关于索引的使用方面1. 尽量的使用索引字段做为查询条件，尤为是汇集索引，必要时能够经过index index_name来强制指定索引2. 避免对大表查询时进行table scan，必要时考虑新建索引。3. 在使用索引字段做为条件时，若是该索引是联合索引，那么必须使用到该索引中的第一个字段做为条件时才能保证系统使用该索引，不然该索引将不会被使用。4. 要注意索引的维护，周期性重建索引。

1.要尽可能避免在where子句中对字段进行NULL值判断；
2.要尽可能避免在where子句使用<>对字段进行判断；
3.使用exists(not exists)替换in(not in)的使用；
4.使用where字句进行范围判断的时候，尽可能使用>=替换>、<=替换<;
5.多表链接的时候，表名都使用别名，字段都带上别名；
6.尽可能多使用commit提交数据

1.多用EXPLAIN 你的 SELECT 查询
2.纵向、横向分割表，减小表的尺寸（sp_spaceuse）
3.当只要一行数据时使用 LIMIT 1
4.固定长度的表会更快
5.选择正确的存储引擎
6.尽可能用固定代替变长字段

尽可能避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会致使相关列的索引没法使用，最好不要用.
在应用程序、包和过程当中限制使用select * from table这种方式
避免使用耗费资源的操做，带有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL语句会启动SQL引擎执行，耗费资源的排序(SORT)功能. DISTINCT须要一次排序操做, 而其余的至少须要执行两次排序
慎重使用临时表能够极大的提升系统性能
避免在WHERE子句中使用in，not in，or 或者having
在WHERE 语句中，尽可能避免对索引字段进行计算操做
尽可能使用UNION ALL代替UNION
对同一个表的修改整合在一个UPDATE语句来完成

1：复杂的sql拆了吧拆拆会很健康
2：在where中要合理运用你创建的索引
3：like这东西少用
4：不要在where不要对索引字段作运算
5：数字字段在条件中别用''引着
6：在mysql中少用正则
7：数据量大的时候，分页查询把limit优化
8：条件中 =左边的不要用函数去转换你想要的格式，而是去转换=右边的常量
9：select * 换成字段能提升一丁点效率