1.数据和日志文件分开存放在不同磁盘上

数据文件和日志文件的操作会产生大量的I/O。在可能的条件下，日志文件应该存放在一个与数据和索引所在的数据文件不同的硬盘上以分散I/O，同时还有利于数据库的灾难恢复。

2.tempdb数据库单独存放在不同磁盘上

tempdb数据库是其他所有数据库都有可能使用的临时数据库。当使用select into、在没建立索引的列上执行Orderby时就会在tempdb数据库中产生临时表来存储中间数据。由于建立和填充临时表会严重降低系统性能，所以在尽可能的情况下应该为要排序的列建立索引。同时，tempdb数据库是为所有的用户和应用程序共享，所以如果一个用户占据了tempdb数据库的所有空间，则其他数据库将不能再使用。在可能的情况下，tempdb数据库应该单独放置在一个速度更快的硬盘或者RAID阵列上。分离tempdb数据库的I/O操作以加快性能。tempdb数据库应该有适当的容量，以满足用户的需要。应该允许tempdb数据库的空间自动增长。如果设置为不允许自动增长，当查询操作建立了超过tempdb数据库容量的临时表时，操作将无法完成。

适当设置tempdb数据库的增长幅度，过小的增长幅度会产生更多的外部碎片，会占用更多的资源。

3.避免热点数据的发生

在SQLServer7.0之前，对于没有聚集索引的表（堆集表），新插入的数据行总是放置在磁盘中表的物理结尾处。如果并发的用户很多，同时在对表执行插入或者更新数据的操作，这将使得十分繁忙的表的末尾有可能产生数据热点。并发的I/O操作集中对少数页面进行操作，将导致数据库性能的下降。

在SQLServer中，新的数据行的物理存储空间的分配是通过PFS页面来进行的。PFS页面的管理算法将插入操作进行分散来尽量避免产生数据热点。

在设计应用系统和数据库时，要避免在自然增长的列上建立主键，这样有可能导致热点数据的发生。

4.数据类型要少

在设计表时，尽可能少用数据类型。这样一个数据页面上可以保存最多的信息。数据页面就少，检索数据页面的I/O操作就少，所以效率会高。

5.监控和整理空间碎片

文件空间的自动增长提高了自动管理性，但可能导致空间碎片。物理空间与数据的逻辑空间不再连续。定期的监控和空间碎片整理有利于提高I/O性能。

6.使用主数据文件和次要数据文件

每个数据库的一个主数据文件属于主文件组。对于1GB左右规模的数据库，一个数据文件就够了，如果有次要数据文件，主数据文件中有管理次要数据文件的指针。

采用多个数据文件时，主数据文件用于存储系统对象和表，次要数据文件用于存储用户数据和索引。在可能的情况下，主数据文件和次要数据文件可以单独存放在不同的磁盘上以分散I/O。

如果采用多个数据文件，推荐主数据文件存储系统数据，次要数据文件存放用户数据和索引，这样会有助于提高I/O性能。

7.利用文件组改善性能

在大型数据库系统中，可以考虑建立文件组来管理数据文件。将表和索引通过存放在不同的物理磁盘上进行性能监控比较，最后得出优化的存储方案。

8.重视自动增长和自动收缩可能导致的性能问题

数据库文件的自动增长和自动收缩功能对于小型数据库的管理十分有用。但可能导致大型数据库的性能问题。因为文件的自然增长的同时会导致存储碎片的发生。当文件空间变大时，新分配的空间不一定和原来的空间连续。当文件空间收缩时，释放了部分空间。然而当文件又需要增长存储空间却不能利用原先释放的空间，也会导致碎片的发生。

9.分离系统数据和用户数据

将系统数据库和用户数据库分开存放在不同的物理磁盘上有助于改善I/O性能，有助于数据库备份和恢复。

10.优化索引设计

索引的设计对数据库的性能十分重要。具体不再阐述，可参见本博相关文章。

11.定期更新统计信息

SQLServer默认使用基于代价的优化，所以统计信息的及时更新对于查询优化十分重要。

12.定期的一致性检查

定期对数据库进行一致性检查，确保数据库的完整性。

【编辑推荐】

1.查询的模糊匹配

尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用，最好不要用.

解决办法:

其实只需要对该脚本略做改进，查询速度便会提高近百倍。改进方法如下：

a、修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表，用户模糊输入供应商名称时，直接在前台就帮忙定位到具体的供应商，这样在调用后台程序时，这列就可以直接用等于来关联了。

b、直接修改后台——根据输入条件，先查出符合条件的供应商，并把相关记录保存在一个临时表里头，然后再用临时表去做复杂关联

2.索引问题

在做性能跟踪分析过程中，经常发现有不少后台程序的性能问题是因为缺少合适索引造成的，有些表甚至一个索引都没有。这种情况往往都是因为在设计表时，没去定义索引，而开发初期，由于表记录很少，索引创建与否，可能对性能没啥影响，开发人员因此也未多加重视。然一旦程序发布到生产环境，随着时间的推移，表记录越来越多

这时缺少索引，对性能的影响便会越来越大了。

这个问题需要数据库设计人员和开发人员共同关注

法则：不要在建立的索引的数据列上进行下列操作:

◆避免对索引字段进行计算操作

◆避免在索引字段上使用not，<>，!=

◆避免在索引列上使用IS NULL和IS NOT NULL

◆避免在索引列上出现数据类型转换

◆避免在索引字段上使用函数

◆避免建立索引的列中使用空值。

3.复杂操作

部分UPDATE、SELECT 语句写得很复杂（经常嵌套多级子查询）——可以考虑适当拆成几步，先生成一些临时数据表，再进行关联操作

4.update

同一个表的修改在一个过程里出现好几十次，如：

update table1
set col1=...
where col2=...;
update table1
set col1=...
where col2=...
......

象这类脚本其实可以很简单就整合在一个UPDATE语句来完成（前些时候在协助xxx项目做性能问题分析时就发现存在这种情况）

5.在可以使用UNION ALL的语句里，使用了UNION

UNION 因为会将各查询子集的记录做比较，故比起UNION ALL ，通常速度都会慢上许多。一般来说，如果使用UNION ALL能满足要求的话，务必使用UNION ALL。还有一种情况大家可能会忽略掉，就是虽然要求几个子集的并集需要过滤掉重复记录，但由于脚本的特殊性，不可能存在重复记录，这时便应该使用UNION ALL，如xx模块的某个查询程序就曾经存在这种情况，见，由于语句的特殊性，在这个脚本中几个子集的记录绝对不可能重复，故可以改用UNION ALL）

6.在WHERE 语句中，尽量避免对索引字段进行计算操作

这个常识相信绝大部分开发人员都应该知道，但仍有不少人这么使用，我想其中一个最主要的原因可能是为了编写写简单而损害了性能，那就不可取了

9月份在对XX系统做性能分析时发现，有大量的后台程序存在类似用法，如：

......
where trunc(create_date)=trunc(:date1)

虽然已对create_date 字段建了索引，但由于加了TRUNC，使得索引无法用上。此处正确的写法应该是

where create_date>=trunc(:date1) and create_date

或者是

where create_date between trunc(:date1) and trunc(:date1)+1-1/(24*60*60)

注意：因between 的范围是个闭区间（greater than or equal to low value and less than or equal to high value.），

故严格意义上应该再减去一个趋于0的小数，这里暂且设置成减去1秒（1/(24*60*60)），如果不要求这么精确的话，可以略掉这步。

7.对Where 语句的法则

7.1 避免在WHERE子句中使用in，not in，or 或者having。

可以使用 exist 和not exist代替 in和not in。

可以使用表链接代替 exist。Having可以用where代替，如果无法代替可以分两步处理。

例子

SELECT *  FROM ORDERS WHERE CUSTOMER_NAME NOT IN 
(SELECT CUSTOMER_NAME FROM CUSTOMER)

优化


SELECT *  FROM ORDERS WHERE CUSTOMER_NAME not exist 
(SELECT CUSTOMER_NAME FROM CUSTOMER)

7.2 不要以字符格式声明数字，要以数字格式声明字符值。（日期同样）否则会使索引无效，产生全表扫描。

例子使用：

SELECT emp.ename, emp.job FROM emp WHERE emp.empno = 7369;
不要使用：SELECT emp.ename, emp.job FROM emp WHERE emp.empno = ‘7369’

8.对Select语句的法则

在应用程序、包和过程中限制使用select * from table这种方式。看下面例子

使用SELECT empno,ename,category FROM emp WHERE empno = '7369‘
而不要使用SELECT * FROM emp WHERE empno = '7369'

9. 排序

避免使用耗费资源的操作，带有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL语句会启动SQL引擎执行，耗费资源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要执行两次排序

10.临时表

慎重使用临时表可以极大的提高系统性能

【编辑推荐】

影响SQL Server性能的三个关键点

2009-03-06 09:42 佚名希赛网我要评论(0) 字号：T | T

向您介绍SQL Server数据库性能优化调优的三个关键点，包括：逻辑数据库和表的设计、索引的设计和查询语句的设计。

AD：

一、逻辑数据库和表的设计

数据库的逻辑设计、包括表与表之间的关系是优化关系型数据库性能的核心。一个好的逻辑数据库设计可以为优化数据库和应用程序打下良好的基础。

标准化的数据库逻辑设计包括用多的、有相互关系的窄表来代替很多列的长数据表。下面是一些使用标准化表的一些好处。

A:由于表窄，因此可以使排序和建立索引更为迅速。

B:由于多表，所以多镞的索引成为可能。

C:更窄更紧凑的索引。

D:每个表中可以有少一些的索引，因此可以提高insert update delete等的速度，因为这些操作在索引多的情况下会对系统性能产生很大的影响。

E:更少的空值和更少的多余值，增加了数据库的紧凑性由于标准化，所以会增加了在获取数据时引用表的数目和其间的连接关系的复杂性。太多的表和复杂的连接关系会降低服务器的性能，因此在这两者之间需要综合考虑。

定义具有相关关系的主键和外来键时应该注意的事项主要是：用于连接多表的主键和参考的键要有相同的数据类型。

二、索引的设计

A:尽量避免表扫描

检查你的查询语句的where子句，因为这是优化器重要关注的地方。包含在where里面的每一列（column)都是可能的侯选索引，为能达到最优的性能，考虑在下面给出的例子：对于在where子句中给出了column1这个列。

下面的两个条件可以提高索引的优化查询性能！

第一：在表中的column1列上有一个单索引；

第二：在表中有多索引，但是column1是第一个索引的列。

避免定义多索引而column1是第二个或后面的索引，这样的索引不能优化服务器性能。

例如：下面的例子用了pubs数据库。

SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = ’White’

按下面几个列上建立的索引将会是对优化器有用的索引

au_lname
au_lname, au_fname

而在下面几个列上建立的索引将不会对优化器起到好的作用

au_address
au_fname, au_lname

考虑使用窄的索引在一个或两个列上，窄索引比多索引和复合索引更能有效。用窄的索引，在每一页上将会有更多的行和更少的索引级别（相对与多索引和复合索引而言），这将推进系统性能。对于多列索引，SQL Server维持一个在所有列的索引上的密度统计（用于联合）和在第一个索引上的histogram（柱状图）统计。根据统计结果，如果在复合索引上的第一个索引很少被选择使用，那么优化器对很多查询请求将不会使用索引。

有用的索引会提高select语句的性能，包括insert,uodate,delete。但是，由于改变一个表的内容，将会影响索引。每一个insert,update,delete语句将会使性能下降一些。实验表明，不要在一个单表上用大量的索引，不要在共享的列上（指在多表中用了参考约束）使用重叠的索引。

在某一列上检查唯一的数据的个数，比较它与表中数据的行数做一个比较。这就是数据的选择性，这比较结果将会帮助你决定是否将某一列作为侯选的索引列，如果需要，建哪一种索引。你可以用下面的查询语句返回某一列的不同值的数目。

select count(distinct cloumn_name) from table_name

假设column_name是一个10000行的表，则看column_name返回值来决定是否应该使用，及应该使用什么索引。

Unique values Index

5000 Nonclustered index
20 Clustered index
3 No index

镞索引和非镞索引的选择

<1>镞索引是行的物理顺序和索引的顺序是一致的。页级，低层等索引的各个级别上都包含实际的数据页。一个表只能是有一个镞索引。由于update,delete语句要求相对多一些的读操作，因此镞索引常常能加速这样的操作。在至少有一个索引的表中，你应该有一个镞索引。

在下面的几个情况下，你可以考虑用镞索引：

例如：某列包括的不同值的个数是有限的（但是不是极少的）

顾客表的州名列有50个左右的不同州名的缩写值，可以使用镞索引。

例如：对返回一定范围内值的列可以使用镞索引，比如用between,>,>=,<,<=等等来对列进行操作的列上。

select * from sales where ord_date between ’5/1/93’ and ’6/1/93’

例如：对查询时返回大量结果的列可以使用镞索引。

SELECT * FROM phonebook WHERE last_name = ’Smith’

当有大量的行正在被插入表中时，要避免在本表一个自然增长（例如，identity列）的列上建立镞索引。如果你建立了镞的索引，那么insert的性能就会大大降低。因为每一个插入的行必须到表的最后，表的最后一个数据页。

当一个数据正在被插入（这时这个数据页是被锁定的），所有的其他插入行必须等待直到当前的插入已经结束。

一个索引的叶级页中包括实际的数据页，并且在硬盘上的数据页的次序是跟镞索引的逻辑次序一样的。

<2>一个非镞的索引就是行的物理次序与索引的次序是不同的。一个非镞索引的叶级包含了指向行数据页的指针。

在一个表中可以有多个非镞索引，你可以在以下几个情况下考虑使用非镞索引。

在有很多不同值的列上可以考虑使用非镞索引

例如：一个part_id列在一个part表中

select * from employee where emp_id = ’pcm9809f’

查询语句中用order by 子句的列上可以考虑使用镞索引。

三、查询语句的设计

SQL Server优化器通过分析查询语句，自动对查询进行优化并决定最有效的执行方案。优化器分析查询语句来决定那个子句可以被优化，并针对可以被优化查询的子句来选择有用的索引。最后优化器比较所有可能的执行方案并选择最有效的一个方案出来。

在执行一个查询时，用一个where子句来限制必须处理的行数，除非完全需要，否则应该避免在一个表中无限制地读并处理所有的行。

例如下面的例子，

select qty from sales where stor_id=7131

是很有效的比下面这个无限制的查询

select qty from sales

避免给客户的最后数据选择返回大量的结果集。允许SQL Server运行满足它目的的函数限制结果集的大小是更有效的。

这能减少网络I/O并能提高多用户的相关并发时的应用程序性能。因为优化器关注的焦点就是where子句的查询，以利用有用的索引。在表中的每一个索引都可能成为包括在where子句中的侯选索引。为了最好的性能可以遵照下面的用于一个给定列column1的索引。

第一：在表中的column1列上有一个单索引；

第二：在表中有多索引，但是column1是第一个索引的列不要在where子句中使用没有column1列索引的查询语句，并避免在where子句用一个多索引的非第一个索引的索引。

这时多索引是没有用的。

For example, given a multicolumn index on the au_lname, 
au_fname columns of the authors table in 
the pubs database,

下面这个query语句利用了au_lname上的索引

SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = ’White’
AND au_fname = ’Johnson’
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = ’White’

下面这个查询没有利用索引，因为他使用了多索引的非第一个索引的索引

SELECT au_id, au_lname, au_fname FROM authors
WHERE au_fname = ’Johnson’

【编辑推荐】

【责任编辑：彭凡 TEL：（010）68476606】

sql的优化

浅谈如何优化SQL Server服务器

高手详解SQL性能优化十条经验

影响SQL Server性能的三个关键点