50种方法优化SQL Server数据库查询
查询速度慢的原因很多，常见如下几种：
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)。
2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足。
5、网络速度慢。
6、查询出的数据量过大(可以采用多次查询，其他的方法降低数据量)。
7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)。
8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。
9、返回了不必要的行和列。
10、查询语句不好，没有优化。
可以通过如下方法来优化查询：
1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb 应放在RAID0上，SQL2000不再支持。数据量(尺寸)越大，提高I/O越重要。
2、纵向、横向分割表，减少表的尺寸(sp_spaceuse)。
3、升级硬件。
4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当(最好是使用默认值0)。索引应该尽量小，使用字节数小的列来建索引(参照索引的创建),不要对有限的几个值的字段建立单一索引，如性别字段等。
5、提高网速，解决因网络速度慢所引起的查询慢问题。
6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。运行Microsoft SQL Server
2000 时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的1.5 倍。如果另外安装了全文检索功能，并打算运行Microsoft搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的3倍。将SQL Server max server memory 服务器配置选项配置为物理内存的1.5 倍(虚拟内存大小设置的一半)。
7、增加服务器CPU个数;但是必须明白并行处理串行处理更需要资源，如内存。使用并行还是串行程序是SQL自动评估选择的。单个任务分解成多个任务，就可以在处理器上运行。例如单个查询的排序、连接、扫描和GROUP BY字句同时执行，SQL SERVER根据系统的负载情况决定最优的并行等级，复杂的需要消耗大量的CPU的查询最适合并行处理，但是更新操作Update，Insert，Delete还不能并行处理。
8、如果是使用like进行查询的话，简单的使用index是不行的，但是全文索引又耗空间。like 'a%' 使用索引like '%a' 和不使用索引用like '%a%' 查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是VARCHAR，对于字段的值很长的建议全文索引。
9、DB Server 和Application Server 分离;OLTP和OLAP分离。
10、分布式分区视图可用于实现数据库服务器联合体。联合体是一组分开管理的服务器，但它们相互协作分担系统的处理负荷。这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器，以支持大型的多层Web 站点的处理需要。有关更多信息，参见设计联合数据库服务器。(参照SQL帮助文件'分区视图')
a、在实现分区视图之前，必须先水平分区表
b、在创建成员表后，在每个成员服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。这样，引用分布式分区视图名的查询可以在任何一个成员服务器上运行。系统操作如同每个成员服务器上都有一个原始表的复本一样，但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。
11、重建索引DBCC REINDEX ,DBCC INDEXDEFRAG,收缩数据和日志DBCC SHRINKDB,DBCC SHRINKFILE. 设置自动收缩日志.对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。在T-sql的写法上有很大的讲究，下面列出常见的要点：首先，DBMS处理查询计划的过程是这样的：
a、查询语句的词法、语法检查。
b、将语句提交给DBMS的查询优化器。
c、优化器做代数优化和存取路径的优化。
d、由预编译模块生成查询规划。
e、然后在合适的时间提交给系统处理执行。
f、最后将执行结果返回给用户其次，看一下SQL SERVER的数据存放的结构：一个页面的大小为8K(8060)字节，8个页面为一个盘区，按照B树存放。
12、Commit和Rollback的区别。Rollback:回滚所有的事务，Commit:提交当前的事务。没有必要在动态SQL里写事务，如果要写请写在外面如：begin tran exec(@s) commit trans 或者将动态SQL 写成函数或者存储过程。
13、在查询Select语句中用Where字句限制返回的行数,避免全表扫描,如果返回不必要的数据，浪费了服务器的I/O资源，加重了网络的负担，降低性能。如果表很大，在全表扫描的期间会将表锁住，禁止其他的联接访问表,后果严重。
14、SQL的注释申明对执行没有任何影响。
15、尽可能不使用光标，它占用大量的资源。如果需要row-by-row地执行，尽量采用
非光标技术,如：在客户端循环，用临时表，Table变量，用子查询，用Case语句等等。游
标可以按照它所支持的提取选项进行分类，必须按照从第一行到最后一行的顺序提取行。FETCH NEXT 是唯一允许的提取操作,也是默认方式。可滚动性可以在游标中任何地方随机提取任意行。游标的技术在SQL2000下变得功能很强大，它的目的是支持循环。有四个并
发选项READ_ONLY：不允许通过游标定位更新(Update)，且在组成结果集的行中没有锁。OPTIMISTIC WITH values:乐观并发控制是事务控制理论的一个标准部分。乐观并发控制用于这样的情形，即在打开游标及更新行的间隔中，只有很小的机会让第二个用户更新某一行。
当某个游标以此选项打开时，没有锁控制其中的行，这将有助于最大化其处理能力。如果用户试图修改某一行，则此行的当前值会与最后一次提取此行时获取的值进行比较。如果任何值发生改变，则服务器就会知道其他人已更新了此行，并会返回一个错误。如果值是一样的，服务器就执行修改。选择这个并发选项 OPTIMISTIC WITH ROW VERSIONING:此乐观并发控制选项基于行版本控制。使用行版本控制，其中的表必须具有某种版本标识符，服务器可用它来确定该行在读入游标后是否有所更改。
在SQL Server 中，这个性能由timestamp 数据类型提供，它是一个二进制数字，表示数据库中更改的相对顺序。每个数据库都有一个全局当前时间戳值：@@DBTS。每次以任
何方式更改带有timestamp 列的行时，SQL Server 先在时间戳列中存储当前的@@DBTS 值，然后增加@@DBTS 的值。如果某个表具有timestamp列，则时间戳会被记到行级。
服务器就可以比较某行的当前时间戳值和上次提取时所存储的时间戳值，从而确定该行是否已更新。服务器不必比较所有列的值，只需比较timestamp 列即可。如果应用程序对没有timestamp 列的表要求基于行版本控制的乐观并发，则游标默认为基于数值的乐观并发控制。
SCROLL LOCKS 这个选项实现悲观并发控制。在悲观并发控制中，在把数据库的行读入游标结果集时，应用程序将试图锁定数据库行。在使用服务器游标时，将行读入游标时会在其上放置一个更新锁。如果在事务内打开游标，则该事务更新锁将一直保持到事务被提交
或回滚;当提取下一行时，将除去游标锁。如果在事务外打开游标，则提取下一行时，锁就被丢弃。因此，每当用户需要完全的悲观并发控制时，游标都应在事务内打开。更新锁将阻止任何其它任务获取更新锁或排它锁，从而阻止其它任务更新该行。
然而，更新锁并不阻止共享锁，所以它不会阻止其它任务读取行，除非第二个任务也在要求带更新锁的读取。滚动锁根据在游标定义的Select 语句中指定的锁提示，这些游标并发选项可以生成滚动锁。滚动锁在提取时在每行上获取，并保持到下次提取或者游标关闭，以先发生者为准。下次提取时，服务器为新提取中的行获取滚动锁，并释放上次提取中行的滚动锁。滚动锁独立于事务锁，并可以保持到一个提交或回滚操作之后。如果提交时关闭游标的选项为关，则COMMIT 语句并不关闭任何打开的游标，而且滚动锁被保留到提交之后，以维护对所提取数据的隔离。所获取滚动锁的类型取决于游标并发选项和游标Select 语句中的锁提示。
16、用Profiler来跟踪查询，得到查询所需的时间，找出SQL的问题所在;用索引优化器优化索引。
17、注意Union和Union all 的区别。Union all好。
18、注意使用DISTINCT，在没有必要时不要用，它同UNION一样会使查询变慢。重复的记录在查询里是没有问题的。
19、查询时不要返回不需要的行、列。
20、用sp_configure 'query governor cost limit'或者SET
QUERY_GOVERNOR_COST_LIMIT来限制查询消耗的资源。当评估查询消耗的资源超出限制时，服务器自动取消查询,在查询之前就扼杀掉。SET LOCKTIME设置锁的时间。
21、用select top 100 / 10 Percent 来限制用户返回的行数或者SET ROWCOUNT来限制操作的行。
22、在SQL2000以前，一般不要用如下的字句: "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'"，因为它们不走索引全是全表扫描。也不要在Where字句中的列名加函数，如Convert，substring等,如果必须用函数的时候，创建计算列再创建索引来替代.还可以变通写法：Where SUBSTRING(firstname,1,1) = 'm'改为Where firstname like 'm%'(索引扫描)，一定要将函数和列名分开。并且索引不能建得太多和太大。NOT IN会多次扫描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 来替代，特别是左连接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，现在2000的优化器能够处理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能优化它，而"<>"等还是不能优化，用不到索引。
23、使用Query Analyzer，查看SQL语句的查询计划和评估分析是否是优化的SQL。一般的20%的代码占据了80%的资源，我们优化的重点是这些慢的地方。
24、如果使用了IN或者OR等时发现查询没有走索引，使用显示申明指定索引：Select * FROM PersonMember (INDEX = IX_Title) Where processid IN ('男'，'女')
25、将需要查询的结果预先计算好放在表中，查询的时候再Select。这在SQL7.0以前是最重要的手段。例如医院的住院费计算。
26、MIN() 和MAX()能使用到合适的索引。
27、数据库有一个原则是代码离数据越近越好，所以优先选择Default,依次为
Rules,Triggers, Constraint(约束如外健主健Check UNIQUE……,数据类型的最大长度等等都是约束),Procedure.这样不仅维护工作小，编写程序质量高，并且执行的速度快。
28、如果要插入大的二进制值到Image列，使用存储过程，千万不要用内嵌Insert来插入(不知JAVA是否)。因为这样应用程序首先将二进制值转换成字符串(尺寸是它的两倍)，服务器受到字符后又将他转换成二进制值.存储过程就没有这些动作: 方法：Create procedure p_insert as insert into table(Fimage) values (@image), 在前台调用这个存储过程传入二进制参数，这样处理速度明显改善。
29、Between在某些时候比IN 速度更快,Between能够更快地根据索引找到范围。用查询优化器可见到差别。select * from chineseresume where title in ('男','女') 和Select * from chineseresume where title between '男' and '女' 是一样的。由于in会比较多次，所以有时会慢些。
30、在必要时对全局或者局部临时表创建索引，有时能够提高速度，但不是一定会这样，因为索引也耗费大量的资源。它的创建同实际表一样。
31、不要建没有作用的事务例如产生报表时，浪费资源。只有在必要使用事务时使用它。
32、用OR的字句可以分解成多个查询，并且通过UNION 连接多个查询。他们的速度只和是否使用索引有关,如果查询需要用到联合索引，用Union all执行的效率更高.多个OR 的字句没有用到索引，改写成UNION的形式再试图与索引匹配。一个关键的问题是否用到索引。
33、尽量少用视图，它的效率低。对视图操作比直接对表操作慢,可以用stored procedure 来代替她。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。我们看视图的本质：它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时，不要使用指向多个表的视图，直接从表检索或者仅仅包含这个表的视图上读，否则增加了不必要的开销,查询受到干扰.为了加快视图的查询，MsSQL增加了视图索引的功能。
35、在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，减少判断的次数。
36、当用Select INTO时，它会锁住系统表(sysobjects，sysindexes等等)，阻塞其他的连接的存取。创建临时表时用显示申明语句，而不是select INTO. drop table t_lxh begin tran select * into t_lxh from chineseresume where name = 'XYZ' --commit 在另一个连接中Select * from sysobjects可以看到Select INTO 会锁住系统表，Create table 也会锁系统表(不管是临时表还是系统表)。所以千万不要在事务内使用它!这样的话如果是经常要用的临时表请使用实表，或者临时表变量。
37、一般在GROUP BY 和HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优：select 的Where字句选择所有合适的行，Group By用来分组个统计行，Having字句用来剔除多余的分组。这样Group By 个Having 的开销小，查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group BY的目的不包括计算，只是分组，那么用Distinct更快。
38、一次更新多条记录比分多次更新每次一条快,就是说批处理好。
39、少用临时表，尽量用结果集和Table类性的变量来代替它,Table 类型的变量比临时表好。
40、在SQL2000下，计算字段是可以索引的，需要满足的条件如下：
a、计算字段的表达是确定的
b、不能用在Text，Next，Image数据类型
c、必须配制如下选项ANSI_NULLS = ON, ANSI_PADDINGS = ON, …….
41、尽量将数据的处理工作放在服务器上，减少网络的开销，如使用存储过程。存储过程是编译好、优化过、并且被组织到一个执行规划里、且存储在数据库中的SQL语句，是控制流语言的集合，速度当然快。反复执行的动态SQL,可以使用临时存储过程，该过程(临
时表)被放在Tempdb中。以前由于SQL SERVER对复杂的数学计算不支持，所以不得不将这个工作放在其他的层上而增加网络的开销。SQL2000支持UDFs,现在支持复杂的数学计算，函数的返回值不要太大，这样的开销很大。用户自定义函数象光标一样执行的消耗大量的资源，如果返回大的结果采用存储过程。
42、不要在一句话里再三的使用相同的函数，浪费资源,将结果放在变量里再调用更快。
43、Select COUNT(*)的效率教低，尽量变通他的写法，而EXISTS快.同时请注意区别：select count(Field of null) from Table 和select count(Field of NOT null) from Table 的返回值
是不同的!
44、当服务器的内存够多时，配制线程数量= 最大连接数+5，这样能发挥最大的效率;否则使用配制线程数量<最大连接数启用SQL SERVER的线程池来解决,如果还是数量=
最大连接数+5，严重的损害服务器的性能。
45、按照一定的次序来访问你的表。如果你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。如果你(不经意的)某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好，死锁很难被发现。
46、通过SQL Server Performance Monitor监视相应硬件的负载Memory: Page Faults / sec 计数器如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。
Process：
1）DPC Time 指在范例间隔期间处理器用在缓延程序调用(DPC)接收和提供服务的百
分比。(DPC 正在运行的为比标准间隔优先权低的间隔)。由于DPC 是以特权模式执行的，DPC 时间的百分比为特权时间百分比的一部分。这些时间单独计算并且不属于间隔计算总数的一部分。这个总数显示了作为实例时间百分比的平均忙时。
2）Processor Time计数器如果该参数值持续超过95%，表明瓶颈是CPU。可以考虑
增加一个处理器或换一个更快的处理器。
3）Privileged Time 指非闲置处理器时间用于特权模式的百分比。(特权模式是为操作系统组件和操纵硬件驱动程序而设计的一种处理模式。它允许直接访问硬件和所有内存。另一种模式为用户模式，它是一种为应用程序、环境分系统和整数分系统设计的一种有限处理模式。操作系统将应用程序线程转换成特权模式以访问操作系统服务)。特权时间的% 包括
为间断和DPC 提供服务的时间。特权时间比率高可能是由于失败设备产生的大数量的间隔而引起的。这个计数器将平均忙时作为样本时间的一部分显示。
4）% User Time表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
吉林化工学院理学院 毕业论文外文翻译 阿德里恩.甘卡，伊莫.盖格尔罗马尼亚布加勒斯特迪杜奥列斯库大学德国派尔博登施泰特威廉学校 数据库优化服务Database Optimizing Services 学生学号：******** 学生姓名：*** 专业班级：信息与计算科学0801 指导教师：*** 职称：教授 起止日期：2012.2.27～2012.3.14 吉林化工学院 Jilin Institute of Chemical Technology
数据库优化服务 摘要 几乎每一个组织都存在它的中心数据库。数据库为不同的活动提供支持，无论是生产，销售和市场营销或内部运作。为了获得战略决策的帮助，一个数据库每天都在被访问。要满足这种需求，因此需要与高品质的安全性和可用性。 为实现一些需求所使用的DBMS（数据库管理系统），事实上，是一个数据库软件。从技术上讲，它是软件，它采用了标准的编目，恢复和运行不同的数据查询方法。DBMS 管理输入数据，组织安排这些数据，并提供它的用户或其他程序修改或提取数据的方法。数据库管理就是一种需要定期更新，优化和监测的操作。 关键词 数据库，数据库管理系统（DBMS），索引，优化，成本，优化数据库。
1 引言 该文件的目的是介绍有关数据库的基本优化代表的观念，在不同类型的查询中使用数学估计成本，可以达到性能水平的审查，以及分析在特定查询的例子中不同的物理访问结构的影响。目标群体应该熟悉SQL在关系数据库的基本概念。 通过这种方式，可以执行复杂的查询策略，允许以较低的成本获得信息的使用知识。一个数据库经过一系列转换，直到其最终用途，以数据建模，数据库设计和开发为开始，以维护和优化为结束。 2 数据库建模 2.1 数据建模 数据模型更侧重于数据是必要的，而做出数据的方式应该是一种有组织的和少操作的方式。数据建模阶段涉及结构的完整性，操作和查询。这有多个这方面的事项，如：1。数据定义方式应该是有组织的（分层网络，关系和重点对象）。这需要提供一个规则，来约束实例的定义结构的允许/限制。 2。提供了数据更新协议。 3。提供了数据查询的方法。 一个结构简单的数据通信，能够使得最终用户很容易的理解，是数据建模想要的的实际结果。 2.2 自定义数据库/数据库发展 数据库的开发和自定义答复了顾客的需求。自定义数据库的重要性主要体现在通过它，使向目标客户直接提供服务的产品的商业化成为可能。一个数据库的质量通过定期更新来维护。 2.3 数据库设计 如果数据库有以下任何问题，如故障，不安全或不准确的数据或数据库退化，失去了其灵活性，那么是时候换新数据库了。因此，必须定义具体的数据类型和存储机制以便通过规则和正确地运用操作机制，确保数据的完整性。所有数据库应构建一个客户方面的规范，包括它的用户界面和功能。通过这些可以使运用数据进入一个网站成为可能。
SQL SERVER性能优化综述 近期因工作需要，希望比较全面的总结下SQL SERVER数据库性能优化相关的注意事项，在 网上搜索了一下,发现很多文章,有的都列出了上百条,但是仔细看发现，有很多似是而非或 者过时(可能对SQL SERVER6.5以前的版本或者ORACLE是适用的)的信息，只好自己根据以 前的经验和测试结果进行总结了。 我始终认为，一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优的任务，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意，进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能 性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能 有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP（联机事务处理系统）和OLAP（联机分析处理系统）。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能 调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效 率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式： 第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组 成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三
大型ORACLE数据库优化设计方案 本文主要从大型数据库ORACLE环境四个不同级别的调整分析入手，分析ORACLE的系统结构和工作机理，从九个不同方面较全面地总结了ORACLE数据库的优化调整方案。 对于ORACLE数据库的数据存取，主要有四个不同的调整级别，第一级调整是操作系统级 包括硬件平台,第二级调整是ORACLE RDBMS级的调整,第三级是数据库设计级的调整,最后一个调整级是SQL级。通常依此四级调整级别对数据库进行调整、优化，数据库的整体性能会得到很大的改善。下面从九个不 同方面介绍ORACLE数据库优化设计方案。 一.数据库优化自由结构OFA(Optimal flexible Architecture) 数据库的逻辑配置对数据库性能有很大的影响,为此,ORACLE公司对表空间设计提出了一种优化结构OFA。使用这种结构进行设计会大大简化物理设计中的数据管理。优化自由结构OFA,简单地讲就是在数据库中可以高效自由地分布逻辑数据对象,因此首先要对数据库中的逻辑对象根据他们的使用方式和物理结构对数据库的影响来进行分类,这种分类包括将系统数据和用户数据分开、一般数据和索引数据分开、低活动表和高活动表分开等等。数据库逻辑设计的结果应当符合下面的准则：(1)把以同样方式使用的段类型存储在一起； (2)按照标准使用来设计系统；(3)存在用于例外的分离区域；(4)最小化表空间冲突；(5)将数 据字典分离。 二、充分利用系统全局区域SGA(SYSTEM GLOBAL AREA) SGA是oracle数据库的心脏。用户的进程对这个内存区发送事务，并且以这里作为高速缓存读取命中的数据，以实现加速的目的。正确的SGA大小对数据库的性能至关重要。SGA 包括以下几个部分： 1、数据块缓冲区(data block buffer cache)是SGA中的一块高速缓存，占整个数据库大小 的1%-2%，用来存储从数据库重读取的数据块(表、索引、簇等)，因此采用least recently used (LRU,最近最少使用)的方法进行空间管理。 2、字典缓冲区。该缓冲区内的信息包括用户账号数据、数据文件名、段名、盘区位置、表 说明和权限，它也采用LRU方式管理。 3、重做日志缓冲区。该缓冲区保存为数据库恢复过程中用于前滚操作。 4、SQL共享池。保存执行计划和运行数据库的SQL语句的语法分析树。也采用LRU算法 管理。如果设置过小，语句将被连续不断地再装入到库缓存，影响系统性能。 另外，SGA还包括大池、JAVA池、多缓冲池。但是主要是由上面4种缓冲区构成。对这
如何优化sql语句.txt心态决定状态，心胸决定格局，眼界决定境界。当你的眼泪忍不住要流出来的时候，睁大眼睛，千万别眨眼，你会看到世界由清晰到模糊的全过程。2010-01-18 honglove (高级程序员) 1、查询时不返回不需要的行、列 业务代码要根据实际情况尽量减少对表的访问行数，最小化结果集，在查询时，不要过多地使用通配符如：select * from table1语句，要用到几列就选择几列，如：select col1,col2 from table1;在可能的情况下尽量限制结果集行数如：select top 100 col1,col2,col3 from talbe2,因为某些情况下用户是不需要那么多的数据的。 2、合理使用EXISTS, NOT EXISTS字句 如下所示： SELECT SUM(T1.C1) FROM T1 WHERE ((SELECT COUNT(*) FROM T2 WHERE T2.C2=T1.C2)>0) SELECT SUM(T1.C1) FROM T1 WHERE EXISTS(SELECT * FROM T2 WHERE T2.C2=T1.C2) 两种产生相同的结果，但是后者的效率显然要高过于前者。银行后者不会产生大量锁定的表扫描或是索引扫描。 经常需要些一个T_SQLL语句比较一个父结果集和子结果集，从而找到是否存在在父结果集中有而在子结果集中乜嘢的记录，如： SELECT _a.hdr_key FROM hdr_tb1 a -----------tb1 a 表示tb1用别名a代替 WHERE NOT EXISTS (SELECT * FROM dt1_tb1 b WHERE a.hdr_key = b.hdr_key) SELECT _a.hdr_key FROM hdr_tb1 a -----------tb1 a 表示tb1用别名a代替 LEFT JION dt1_tb1 b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL SELECT hdr_key FROM hdr_tb1
1.1、数据库及SQL代码优化方案 （1）每周检查统计信息是否及时更新。 （2）每周检查各索引是否有效。 （3）每周检查分区是否正确。 （4）每周检查执行计划是否正确。 （5）每天检查RAC和ASM是否正常运行。 （6）每天检查相关日志是否正常备份。 （7）每天检查相关文件系统和表空间的占用率是否在国家税务总局规定的阀值以下。 （8）在每月申报高峰等业务繁忙期采样并找出消耗I/O资源和CPU资源较多的SQL语句。 （9）分析上述SQL语句，与软件服务商充分沟通后，提出优化建议。 （10）在每月申报高峰期每隔15分钟检查一次数据库连接数，发现异常及时处理。 1.1.1、系统数据库索引、表分区和对象优化方案 数据库对象的优化主要包括：表、索引和sequence等对象，通过优化对象参数、调整对象属性（例如分区表、分区索引、反转索引等等）等方法来实现对数据库对象的优化改造。 1.1.1.1表和索引并行参数优化 数据库的表和索引的并行参数值的设置对相关的sql语句的执行计划会造成影响，表和索引的degree值大于1，执行计划就偏向于使用全表和全索引扫描，另外如果并行参数值过大，短时间内也会对主机和数据库的资源造成很大的压力，因此在oltp的数据库下建议将表和索引的degree值设为1。 1.1.1.2热点大表的分区改造 对访问量很大、表的记录数很多、存在热块争用的表，可以考虑对表和索引进行适当的分区改造，分散访问压力，提高数据访问的性能。 对以下表的记录数超过1000万并且记录数持续增长的大表，建议进行分区
改造（地区+时间）： 1.1.1.3分区索引的清理 对最近30天数据库分区索引访问情况进行统计，对访问次数为0的分区索引和应用部门进行确认，若确认为多余的索引，建议进行删除清理。 1.1.1.4Sequence序列优化 加大sequence 的 cache，并使用noorder选项。在RAC中经常会遇到SQ 锁等待，这是因为在RAC环境下，sequence也成为全局性的了，不同节点要生成序列号，就会产生对sequence资源的争用。而目前大多数系统中，sequence 大多数被作为主键发生器来使用，使用的频率十分高，在RAC环境中，需要设置较大的 sequence cache，否则会造成较为严重的争用，从而影响业务。 1.1.2、SQL硬解析优化方案 1.1. 2.1相关知识点介绍 1.1. 2.1.1Oracle的硬解析和软解析 Oracle对sql的处理过程：当发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程： 1、语法检查(syntax check) 检查此sql的拼写是否语法。 2、语义检查(semantic check) 诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。 3、对sql语句进行解析(prase) 利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution plan)。 4、执行sql，返回结果(execute and return) 其中，软、硬解析就发生在第三个过程里。 Oracle利用内部的hash算法来取得该sql的hash值，然后在library cache
OLTP数据库优化方案及案例
ORACLE数据库SQL优化方案、案例
Edgar Liu
? 2015 Huatek CO., LTD. All Rights Reserved.
2015.3.17
目录
1. 优化方案与基础知识
1.1 问题SQL来源（现象） 1.2 数据库性能优化方案及期待效果 1.3 优化方法论及优化分析树 1.4 数据库体系结构 1.5 逻辑读 逻辑写
4.索引设计与查询条件
4.1 4.2 4.3 4.4 索引介绍 索引设计步骤 索引创建原则 索引失效与不足
2. 执行计划分析
2.1 执行计划查看方法 2.2 执行计划示例 2.3 执行计划三部分 2.4 硬解析和软解析
5. 高效SQL
5.1 5.2 5.3 5.4 优化规则30条 关于Hit提示优化 DML语句优化 批量读取游标数据优化
3.最佳表连接方式
3.1 3.2 3.3 3.4 ORACLE表介绍 RDBMS表连接方式介绍 执行计划中表连接方式介绍 执行计划中表连接方式比较
6. 数据模型与SQL
6.1 数据逻辑模型设计 6.2 数据库物理设计 6.3 书集推荐
2/40
1.0 OLTP 与OLAP区别
?对于Oracle数据库的数据存取，主要有四个不同的调整级别， ?第一级调整是操作系统级包括硬件平台, ?第三级是Oracle数据库设计级的调整, 第二级调整是Oracle RDBMS级的调整, 第四级调整级是SQL级。通常依此四级调整级别对数据库进行调
整、优化，数据库的整体性能会得到很大的改善。
3/40
浅谈优化SQLServer数据库服务器内存配置的策略 浅谈优化SQLServer数据库服务器内存配置的策略 作者：季广胜 言 农业银行总行1998年以来正式推广了新版网络版综合业务统计信息系统，该系统是基于WindowsNT4.0平台，采用客户／服务器模式，以Microsoft SQL Server为基础建立起来的大型数据库应用程序，系统界面友好、操作简便，计算、分析、检索功能非常强大，为保证农业银行系统及时进行纵向和横向业务数据采集、按照不同要求生成统计报表，进行全面业务活动分析提供了强有力的保障。但在这套程序的推广、维护中笔者发现系统有时运行速度较慢，特别是在Win95客户端操作时尤为严重，经过排除网线连接等硬件可能带来的影响后上述问题仍然存在。笔者经过仔细摸索，发现系统对硬、软件的要求较高，为充分发挥设计效能，达到最佳运作效果，需要对计算机硬、软件系统进行较为完备的性能测试与最佳配置，特别是内存配置的好坏对系统的运行速度具有决定性的作用。下面，笔者就如何优化SQLServer数据库服务器的内存配置提出一些认识和看法。 一、有关内存的基本概念 1 物理内存与虚拟内存 WindowsNT使用两类内存：物理内存与虚拟内存。
物理内存：作为RAM芯片安装在计算机内部的存储器。 虚拟内存：用于模拟RAM芯片功能的磁盘(硬盘)空间，其实质是通过将内存中当前没有使用的部分内容临时存储到磁盘上，使系统可以使用到比机器物理内存更多的内存。 2 分页和分页文件 WindowsNT系统通过使用磁盘空间使得对内存的需求得到部分缓解，从而使用到比物理内存更多内存的技术就称为“交换”或分页，也就是通常所说的虚拟内存技术。通常Windows NT 4.0系统安装时将在引导驱动器上设置一个大小为16MB的交换(分页)文件(pagefile.sys)。 二、优化Windows NT 4.0系统内存配置 在大多数情况下，为了充分发挥Windows NT 4.0系统效能，内存的作用比起处理器的处理能力更具有影响力，特别是在客户／服务器模式环境下更是如此，因为通常在这种环境下并不十分强调处理器的能力，相反却十分注重是否采用足够的内存来满足各个客户的应用需要。此外，为了获得容错功能和保护应用程序，保证应用程序高速运行、充分发挥设计功能都需要有足够多的内存，特别是工业绘图设计和各种工程应用程序更需要占用大量的内存来进行复杂的计算。 物理内存(RAM)方便快速的优点显而易见，但由于其价格昂贵，也就不可能做到多多益善了，因此通过合理优化内存配置、扩充虚拟
高级数据库技术——期末论文 基于SQL查询的MySQL数据库性能优化研究 ：XX 学号:2014XXXXX 学院：计算机学院
摘要： 查询是数据库系统中最基本也是最常用的一种操作，是否具有较快的执行速度，已成为数据库用户和设计者极其关心的问题。在研究开源数据库管理系统MySQL 查询优化技术的基础上，主要结合传统SQL操作优化、深度分析 MySQL 源代码、现代数据库发展几方面进行诸如参数调优，MySQL关联查询，重写相关规则等容展开优化分析研究。 关键词：查询优化，查询重用，查询重写，计划优化
一、传统SQL查询优化操作 1.选取最适用的字段属性 MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。 另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。 2.使用连接（JOIN）来代替子查询(Sub-Queries) MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示： DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo ) 使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，
第四章关系系统及其查询优化 习题 1．试给出各类关系系统的定义：最小关系系统；关系完备上的系统；全关系型的关系系统。 2．试述全关系型系统应满足的十二条准则，以及十二条基本准则的实际意义和理论意义。 3．试述查询优化在关系数据库中的重要性和可能性。 4．对学生-课程数据库有如下的查询： SELECT Cname FROM Student，Course，SC WHERE Student。Sno=SC。Sno AND SC。Cno=Course。Cno AND Student。Sdept=’IS’； 此查询要求信息系学生选修了的所有课程名称。试画出用关系代数表示的语法树，并用关系代数表达式优化算法对原始的语法树进行优化处理，画出优化后的标准优化树。 5．试述查询优化的一般准则。 6．试述查询优化的一般步骤。 参考答案 1．答：最小关系系统。 一个系统可定义为最小关系系统，当且仅当它： （1）支持关系数据库（关系数据结构），从用户观点看，关系数据库由表构成，并且只有表这一种结构 （2）支持选择、投影和（自然）连接运算，对这些运算不必要求定义任何物理存取路径。 关系上完备的系统： 这类系统支持关系数据结构和所有的关系代数操作（或者功能上与关系代数等价的操作）。 全关系型的关系系统： 这类系统支持关系模型的所有特征。即不仅是关系上完备的而且支持数据结构中域的概念，支持实体完整和参照完整性。 2．答：关系模型的奠基人E。F。Codd具体地给出了全关系型的关系系统应遵循的十二条基本准则。从实际意义上看，这十二条准则可以作为评价或购买关系型产品的标准。从理论意义上看，它是对关系数据模型具体而又深入的论述，是从理论和实际紧密结合的高度对关系型DBMSR 评述。 准则0 一个关系型的DBMS必须能完全通过它的关系能力来管理数据库。 准则1信息准则。关系型DBMS的所有信息都应在逻辑一级上用一种方法即表中的值显式地表示。 准则2保证访问准则。依靠表名、主码和列名的组合，保证能以逻辑方式访问关系数据库中的每个数据项（分量值）。 准则3空值的系统化处理。全关系型的DBMS应支持空值的概念，并用系统化的方式处理空值。 准则4基于关系模型的动态的联机数据字典。数据库的描述在逻辑级应该和普通数据采用同样的方式，使得授权用户可以使用查询一般数据所用的关系语言来查询数据库的描述信息。 准则5统一的数据语言准则。 准则6视图更新准则。所有理论上可更新的视图也应该允许由系统更新。 准则7高级的插入、修改和删除操作。 准则8数据物理独立性。无论数据库的数据在存储表示或存取方法上作任何变化，应用程序和终端活动都保持逻辑上的不变性。 准则9数据逻辑独立性。当对基本关系进行理论上信息不受损的任何改变时，应用程序和终端活动都保持逻辑上的不变性。
SQL数据库优化方法
目录 1 系统优化介绍 (1) 2 外围优化 (1) 3 SQL优化 (2) 3.1 注释使用 (2) 3.2 对于事务的使用 (2) 3.3 对于与数据库的交互 (2) 3.4 对于SELECT *这样的语句， (2) 3.5 尽量避免使用游标 (2) 3.6 尽量使用count(1) (3) 3.7 IN和EXISTS (3) 3.8 注意表之间连接的数据类型 (3) 3.9 尽量少用视图 (3) 3.10 没有必要时不要用DISTINCT和ORDER BY (3) 3.11 避免相关子查询 (3) 3.12 代码离数据越近越好 (3) 3.13 插入大的二进制值到Image列 (4) 3.14 Between在某些时候比IN 速度更快 (4) 3.15 对Where条件字段修饰字段移到右边 (4) 3.16 在海量查询时尽量少用格式转换。 (4) 3.17 IS NULL 与IS NOT NULL (4) 3.18 建立临时表， (4) 3.19 Where中索引的使用 (5) 3.20 外键关联的列应该建立索引 (5) 3.21 注意UNion和`UNion all 的区别 (5) 3.22 Insert (5) 3.23 order by语句 (5) 3.24 技巧用例 (6) 3.24.1 Sql语句执行时间测试 (6)
1系统优化介绍 在我们的项目中，由于客户的使用时间较长或客户的数据量大，造成系统运行速度慢，系统性能下降就容易造成数据库阻塞。这是个非常痛苦的事情，用户的查询、新增、修改等需要花很多时间，甚至造成系统死机的现象。速度慢的原因主要是来自于资源不足。 数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。最常见的优化手段就是对硬件的升级。根据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，全部加起来最多只占数据库系统性能提升的40%左右(我将此暂时称之为外围优化)；其余大部分系统性能提升来自对应用程序的优化，对于应用程序的优化可以分为对源代码的优化及数据库SQL语句的优化。在本文档只介绍外围优化及SQL语句的优化，对于源代码的优化需要相关方面的专家，形成统一的规范。 一个数据库系统的生命周期可以分成：设计、开发和成品三个阶段。在设计阶段进行数据库性能优化的成本最低，收益最大。在成品阶段进行数据库性能优化的成本最高，收益最小。规范的代码和高性能的语句，功在平时，利在千秋。 2外围优化 1、将操作系统与SQL数据库的补丁打到最高版本，WIN2003最高补丁是SP4， SQL SERVER2000最高补丁是SP4(版本号：2039)。 2、在服务器上不要安装与VA程序任何无相关的软件，甚至一些与VA运行 无关的服务都可以停掉。一般只安装SQL数据库、VA服务端服务及杀毒 软件。 3、杀毒软件避免对大文件进行扫描，特别是数据库（MDF和LDF）文件，一 定要从杀毒软件的范围内排除掉。 4、在进行服务器分区时，分区不要太多，两三个分区就可以了。分区最好 都使用NTFS格式。
浅谈数据库系统优化 概要：数据库系统的优化可以有效提高系统的性能，微软的SQL Server数据库的优化是一个系统工程，需要从设计开始就进入优化程序。 数据库的性能的优化成了数据处理的一个很重要环节。系统的性能优化应该贯穿系统工作的整个生命周期，从开发开始直到系统最终下线，都应该不断的动态的优化并不断调整优化过程。基于SQL Server的数据库优化是指对数据库处理、存储、查询等进行调优的过程。 基于SQL Serve数据库的优化，应该从数据库设计的时候就做好优化打算，为后面系统正式投入运行后优化做好准备。其主要策略有： 1）调优数据库。数据库性能的优化基础就是数据库的基本设计，如果设计端出了问题则对数据库的影响很大，也很有可能没有优化的必要。数据库的优化应该从数据库的设计开始，一般要找专业的性能优化专家根据系统的要求，对数据库采取合理的设计方案。数据库的设计主要包含两个部分，一个是数据库存储分配的物理设计，一个是数据流量分配的逻辑设计。物理设计主要包括数据对象在物理介质上存储分布等各个方面，所要注意的问题就是在不同的存储介质上所放的数据块的大小，这个直接关系到数据的存储速度。而逻辑设计主要包括在数据库的索引、数据库模式、视图等。数据库的设计是基础，如果在设计初始出了问题，则不可能通过单纯的优化来完成数据库的正常工作，所以这是数据库调整和优化的保障。 2）优化应用程序。网络中数据的查询和传输速度及效率不仅仅在于服务器，而是和多种因素相关联的，根据网络上的相关统计，对和数据库相关的各个外部因素进行调整，同样可以达到数据库性能优化的目的。相关因素主要包括，网络、操作系统、硬件、数据库参数等各个方面。而这因素大都设计硬件设备，其它软件方面主要是应用程序的优化，包括数据库的SQL语句和系统开发语言的优化。在数据库的应用中，大部分是通过SQL语句来实现的，因此SQL语句的优化对数据系统优化起到很重要的作用。 大多数针对系统应用程序的优化也都集中在查询语句的处理上，而SQL语句的优化则可集中到合理利用临时数据表及索引。充分利用临时数据表，及建立合理的索引、调整优化SQL语句，等可以减少客户访问数据库的次数，减小CPU
大型数据库的优化方法及实例 尹德明杨富玉杨莹时鹏泉 中国金融电子化公司 E_mail: dm_mis@https://www.doczj.com/doc/265513763.html, 1.引言 随着银行业数据集中，作为整个系统核心的数据库，其存放、管理的数据越来越庞大，已经超越GB而到达TB数据量层次，数据库的性能成为整个系统性能的关键。 国库会计核算系统是国库部门用以进行国库业务的会计核算，并通过支付系统、国库内部往来、同城票据交换系统进行资金清算的计算机网络系统。国家金库会计核算系统每天处理的税票数据多达10万笔，税收高峰可能会到100万笔，这样一年累计下来其中历史登记簿中的数据达到2000万条以上，给检索和数据处理带来非常大的困难。 如何对于一个已经上线运行的重要业务系统，通过对数据库的优化和简单的系统流程调整，实现系统性能的大幅提升具有现实、迫切、重要的意义。 2.优化策略 根据Sybase的数据存储机制，在进行一段时期的数据删除、插入和更新等操作后，数据库往往会产生大量的碎片。大量碎片的存在，会严重影响数据库的I/O性能，如果在使用数据库一段时间后，整理碎片，可以提高数据库的性能。由于国家金库会计核算系统在预处理、日间报解、日初始化等步骤，会大批量进行数据删除、插入和更新等操作，因此会产生大量的数据碎片。碎片整理对于国家金库会计核算系统性能优化将会有重要效果。 Sybase Adaptive Server对于按顺序存储和访问的页，在单个I/O中最多读取八个数据页。由于大部分I/O时间都花在磁盘上的物理定位和搜寻上，因此大I/O可极大地减少磁盘访问时间。在大多数情况下，希望在缺省数据高速缓存中配置一个16K缓冲池。为事务日志创建4K缓冲池可极大地减少数据库系统日志写操作的数量。 好的性能同优良的数据库设计及优秀的程序写法关系极大，可以这样说，如果一个数据库没有好的设计及对程序未进行优化的话即使对参数进行调整也不可能有好的性能。 3.数据库碎片整理 由于Sybase是通过OAM页、分配单元和扩展页来管理数据的，所以对OLTP应用的Database Server会十分频繁地进行数据删除、插入和更新等操作，时间一长就会出现以下几种情况： (1)页碎片 即本来可以存放在一个页上的数据却分散地存储在多个页上。如果这些页存储在不同的扩展单元上，Database Server就要访问多个扩展单元，因此降低了系统性能。 (2)扩展单元碎片 在堆表中，当删除数据链中间的记录行时，会出现空页。随着空页的累积，扩展单元的利用率也会下降，从而出现扩展单元碎片。带cluster index的table也有可能出现扩展单元碎片。当有扩展单元碎片存在，会出现以下问题： 对表进行处理时，常常出现死锁；利用较大的I/O操作或增加I/O缓冲区的大小也无法改变较慢的I/O速度；行操作的争用。 （3）扩展单元遍历 带有cluster index的table会由于插入记录而导致页分裂，但当删除记录后，页会获得释放，从而形成跨几个扩展单元和分配单元的数据，而要访问该数据就必须遍历几个扩展单元和分配单元。这将导致访问/查询记录的时间大大延长，开始时数据库的性能虽然较高，
SQLServer语句优化 1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷) 我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。 需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。 下面的表总结了何时使用聚集索引或非聚集索引（很重要）： 动作描述使用聚集索引使用非聚集索引 列经常被分组排序应应 返回某范围内的数据应不应 一个或极少不同值不应不应 小数目的不同值应不应 大数目的不同值不应应 频繁更新的列不应应 外键列应应 主键列应应 频繁修改索引列不应应 事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询2004年1月1日至2004年10月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可；而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。 结合实际，谈索引使用的误区 理论的目的是应用。虽然我们刚才列出了何时应使用聚集索引或非聚集索引，但在实践中以上规则却很容易被忽视或不能根据实际情况进行综合分析。下面我们将根据在实践中遇到的实际问题来谈一下索引使用的误区，以便于大家掌握索引建立的方法。 1、主键就是聚集索引 这种想法笔者认为是极端错误的，是对聚集索引的一种浪费。虽然SQL SERVER默认是在主键上建立聚集索引的。 通常，我们会在每个表中都建立一个ID列，以区分每条数据，并且这个ID列是自动增大的，步长一般为1。我们的这个办公自动化的实例中的列Gid就是如此。此时，如果我们将这个列设为主键，SQL SERVER会将此列默认为聚集索引。这样做有好处，就是可以让您的数据在数据库中按照ID进行物理排序，但笔者认为这样做意义不大。 显而易见，聚集索引的优势是很明显的，而每个表中只能有一个聚集索引的规则，这使得聚集索引变得更加珍贵。 从我们前面谈到的聚集索引的定义我们可以看出，使用聚集索引的最大好处就是能够根据查询要求，迅速缩小查询范围，避免全表扫描。在实际应用中，因为ID号是自动生成的，我们并不知道每条记录的ID号，所以我们很难在实践中用ID号来进行查询。这就使让ID号这个主键作为聚集索引成为一种资源浪费。其次，让每个ID号都不同的字段作为聚集索引也不符合“大数目的不同值情况下不应建立聚合索引”规则；当然，这种情况只是针对用户经常修改记录内容，特别是索引项的时候会
SQL Server数据库优化方案汇总 50种方法优化SQL Server 1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷) 2、I/O吞吐量小，形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足 5、网络速度慢 6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量） 7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷) 8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 9、返回了不必要的行和列 10、查询语句不好，没有优化 可以通过如下方法来优化查询 : 1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。数据量（尺寸）越大，提高I/O越重要. 2、纵向、横向分割表，减少表的尺寸(sp_spaceuse) 3、升级硬件 4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（最好是使用默认值0）。索引应该尽量小，使 用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段 5、提高网速; 6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行 配置。运行 Microsoft SQL Server? 2000 时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的 1.5 倍。如果另外安装了全文检索功能，并打算 运行 Microsoft 搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。将 SQL Server max server memory 服务器配置选项配置为物理内存的 1.5 倍（虚拟内存大小设置的一半）。 7、增加服务器 CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成 多个任务，就可以在处理器上运行。例如耽搁查询的排序、连接、扫描和GROUP BY字句同时执行，SQL SERVER根据系统的负载情况决定最优的并 行等级，复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作Update,Insert， Delete还不能并行处理。 8、如果是使用like进行查询的话，简单的使用index是不行的，但是全文索引，耗空间。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是VARCHAR。对于字段的值很长的建全文索引。 9、DB Server 和APPLication Server 分离；OLTP和OLAP分离
SQLserver数据库优化 在使用索引字段作为条件时，如果该索引是联合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用。iv. 如果临时表的数据量较大，需要建立索引，那么应该将创建 查询速度慢的原因很多，常见如下几种： 1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷) 2、I/O吞吐量小，形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足 5、网络速度慢 6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量） 7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷) 8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 9、返回了不必要的行和列 10、查询语句不好，没有优化 可以通过如下方法来优化查询: 1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb 应放在RAID0上，SQL2000不在支持。数据量（尺寸）越大，提高I/O越重要. 2、纵向、横向分割表，减少表的尺寸(sp_spaceuse) 3、升级硬件 4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（最好是使用默认值0）。索引应该尽量小，使用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段 5、提高网速; 6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。配置虚拟
内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。运行Microsoft SQL Server? 2000 时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的1.5 倍。如果另外安装了全文检索功能，并打算运行Microsoft 搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。将SQL Server max server memory 服务器配置选项配置为物理内存的1.5 倍（虚拟内存大小设置的一半）。 7、增加服务器CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成多个任务，就可以在处理器上运行。例如耽搁查询的排序、连接、扫描和GROUP BY字句同时执行，SQL SERVER根据系统的负载情况决定最优的并行等级，复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作Update,Insert，Delete还不能并行处理。 8、如果是使用like进行查询的话，简单的使用index是不行的，但是全文索引，耗空间。like 'a%' 使用索引like '%a' 不使用索引用like '%a%' 查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是V ARCHAR。对于字段的值很长的建全文索引。 9、DB Server 和APPLication Server 分离；OLTP和OLAP分离 10、分布式分区视图可用于实现数据库服务器联合体。联合体是一组分开管理的服务器，但它们相互协作分担系统的处理负荷。这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器，以支持大型的多层Web 站点的处理需要。有关更多信息，参见设计联合数据库服务器。（参照SQL帮助文件'分区视图'） a、在实现分区视图之前，必须先水平分区表 b、在创建成员表后，在每个成员服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。这样，引用分布式分区视图名的查询可以在任何一个成员服务器上运行。系统操作如同每个成员服务器上都有一个原始表的复本一样，但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。 11、重建索引DBCC REINDEX ,DBCC INDEXDEFRAG,收缩数据和日志DBCC SHRINKDB,DBCC SHRINKFILE. 设置自动收缩日志.对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。在T-sql的写法上有很大的讲究，下面列出常见的要点：首先，DBMS处理查询计划的过程是这样的： 1、查询语句的词法、语法检查 2、将语句提交给DBMS的查询优化器 3、优化器做代数优化和存取路径的优化 4、由预编译模块生成查询规划 5、然后在合适的时间提交给系统处理执行
Sql优化方案 一．数据库优化技术 1.索引（强烈建议使用） 1.1优点 创建索引可以大大提高系统的性能。 第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。 第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。 第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。 第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。 第五，通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。 1.2 缺点 第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。 第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。 1.3 使用准则 索引是建立在数据库表中的某些列的上面。因此，在创建索引的时候，应该仔细考虑在哪些列上可以创建索引，在哪些列上不能创建索引。 一般来说，应该在这些列上创建索引。 第一，在经常需要搜索的列上，可以加快搜索的速度；
第二，在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构； 第三，在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；第四，在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的； 第五，在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间； 第六，在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。 同样，对于有些列不应该创建索引。一般来说，不应该创建索引的的这些列具有下列特点： 第一，对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。 第二，对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。 第三，对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。 第四，当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改性能远远大于检索性能时，不应该创建索引。 1.4 总结 1）索引提高了数据库的检索性能，但一定程度上牺牲了修改性能。因此适用于“多查询少修改”（insert，update，delete）的表。 2）对此类表中的外键，需要分组，排序或作为检索条件的字段建立索引 3）对此类表中查询使用少，字段取值少，字段数据量大的不应创建索引