SQL Server数据库性能优化
“猫猫教忠诚教徒”通过精心收集，向本站投稿了10篇SQL Server数据库性能优化，下面是小编为大家整理后的SQL Server数据库性能优化，供大家参考借鉴，希望可以帮助您。
篇1：影响SQLserver性能的关键三个方面数据库
1 逻辑 数据库 和表的设计 数据库的逻辑设计、包括表与表之间的关系是优化关系型数据库 性能 的核心，一个好的逻辑数据库设计可以为优化数据库和应用程序打下良好的基
1 逻辑数据库和表的设计
数据库的逻辑设计、包括表与表之间的关系是优化关系型数据库性能的核心。一个好的逻辑数据库设计可以为优化数据库和应用程序打下良好的基础。
标准化的数据库逻辑设计包括用多的、有相互关系的窄表来代替很多列的长数据表。下面是一些使用标准化
表的一些好处。
A:由于表窄，因此可以使排序和建立索引更为迅速
B:由于多表，所以多镞的索引成为可能
C:更窄更紧凑的索引
D:每个表中可以有少一些的索引，因此可以提高insert update delete等的速度，因为这些操作在索引
多的情况下会对系统性能产生很大的影响
E:更少的空值和更少的多余值，增加了数据库的紧凑性
由于标准化，所以会增加了在获取数据时引用表的数目和其间的连接关系的复杂性。太多的表和复杂的连接关系会降低服务器的性能，因此在这两者之间需要综合考虑。
定义具有相关关系的主键和外来键时应该注意的事项主要是：用于连接多表的主键和参考的键要有相同的数据类型。
2 索引的设计
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 子句的列上可以考虑使用镞索引
3 查询语句的设计
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'
原文转自：www.ltesting.net
篇2：浅析SQL Server数据库的性能优化
在一个大型的数据库中，性能成为人们关注的焦点之一，如何让数据库高效有效的运行成为广大数据库管理人员和开发人员必须要考虑的问题，性能是一个应用或多个应用在相同的环境下运行时对效率的衡量。性能常用响应时间和工作效率来表示。响应时间是指完成一个任务花费的时间，可以从以下三方面来减少响应时间：
· 减少竞争和等待的次数，尤其是磁盘读写等待次数
· 利用更快的部件
· 减少利用资源所需的时间
绝大多数性能的获得来自于优秀的数据库设计、精确的查询分析和适当的索引。最好性能的获得能够通过确立优秀的数据库设计，在开发时学会使用SQL Server查询优化器来实现。
为了取得更好的数据库性能，我们就需要对数据库进行优化，减少系统资源的竞争，如对数据cache，过程cache，系统资源和CPU的竞争。
在SQL Server中，有如下优化层次：
·应用层——大部分性能的获得来自于对你的SQL应用中查询的优化，这必须是以好的数据库设计为基础的。
·数据库层——应用共享在数据库层中的资源，这些资源包括硬盘，事务日志和数据cache。
·服务器层——在服务器层有许多共享的资源，包括数据高速缓存，过程高速缓存，锁，CPU等。
·设备层——指的是存储数据的磁盘及其控制器，在这一层，你应尤其关注磁盘的I/O。
·网络层——指连接用户和SQL Server的网络。
·硬件层——指可利用的CPU。
·操作系统层——理想地，SQL Server是一台机器的唯一主要应用，它必须和操作系统以及其他sybase软件，如Backup Server或SQL Server Monitor共享处理器、内存以及其他资源。
在大多数情况下面，我们是对应用层进行优化，，因为对应用性能的优化是大家最乐于接受的功能，其结果能被观测及检验，查询的性能是SQL应用的整个性能的一个关键。
应用层上的问题包括以下内容：
·决策支持VS.和在线事务处理(OLTP)需要不同的性能策略
·事务设计能够减少并发，因为长的事务保持占用锁，也就减少了其他用户对相关数据的存取
·关联一致性对数据修改需要join操作
·支持Select操作的索引增加了修改数据的时间
·为了安全而设立的审计限制了性能
在应用层优化的选项包括：
·远程处理或复制处理能够把决策支持从OLTP机器中分离出来
·利用存储过程来减少编译时间和网络的利用
·利用最少量的锁去满足你的应用需要
数据库层的问题包括：
·建立备份和恢复方案
·在设备上分布存储数据
·审计操作影响性能;仅审计你所需的
·日常的维护活动将导致性能的降低和导致用户不能操作数据库表
在数据库层上优化选择包括：
·利用事务日志的阀值来自动转储事务日志防止其超出使用空间
·在数据段中用阀值来监视空间的使用
·利用分区来加速数据的装入
·对象的定位以避免硬盘的竞争
·把重要表和索引放入cache中，保证随时取得
服务器层的问题有：
·应用的类型——服务器是支持OLTP还是DSS，或者两者都支持
·所支持的用户数影响优化决策——随着用户数的增加，对资源的竞争会发生改变
·网络负荷
·当用户数和事务数达到一定的数量时复制服务器或其他分布式处理是一个解决的方法
服务器层的优化的选项包括:
·优化内存——一个关键的配置参数和其他方面的参数
·决策是客户端处理还是服务器端处理——有些处理能在客户端进行吗
·配置cache的大小和I/O的大小
·增加多个CPU
·为空闲时间排定批处理任务和生成报表
·工作负荷发生改变，重新配置特定参数
·决定是否可能把DSS移到另一个SQL服务器中设备层
设备层的问题包括：
·主设备、包含用户数据库的设备，用户数据设备，或数据库日志是否要镜像
·怎样在设备之间分布系统数据库、用户数据库和数据库日志
·为获得对堆表插入操作的高性能，是否有必要进行分区
设备层上优化的选项包括：
·用多个中等大小的设备及多个控制器可能比用少量的大设备有更好的I/O性能
·分布数据库，表和索引以在不同的设备上进行I/O装载
网络层
实际上，SQL Server的所有用户都是通过网络存取他们的数据，
网络层上的主要问题有:
·网络的流量
·网络的瓶颈
·网络的速度
网络层上优化的选项包括：
·配置包的大小，以使其与应用的需要相匹配
·配置子网
·分隔出繁忙的网络运用
·创建一个高容量的网络
·配置多个网络引擎
·更好地设计应用，限制所需的网络传输
硬件层
在硬件层上的问题包括
·CPU的效率
·磁盘的存取:控制器和磁盘
·磁盘备份
·内存的使用
在硬件层上优化的选项包括：
·增加CPU以适应工作负荷
·配置调度程序以提高CPU利用率
·遵循多处理器应用设计指导以减少竞争
·配置多个数据cache操作系统层
操作系统层的主要问题有：
·文件系统——是否被SQL Server独占使用
·内存管理——精确估算操作系统和其他程序的内存占用
·CPU的利用——整个系统共有多少处理器可用?有多少分配给SQL Server
在操作系统层优化的选项包括：
·网络接口
·在文件和原始分区之间选择
·增加内存
·把客户操作和批处理移到其他机器上
·SQL Server利用多个CPU
篇3：浅析SQL Server数据库的性能优化数据库
在一个大型的数据库中， 性能 成为人们关注的焦点之一，如何让数据库高效有效的运行成为广大数据库管理人员和 开发 人员必须要考虑的问题，性能是一个应用或多个应用在相同的环境下运行时对效率的衡量。性能常用响应时间和工作效率来表示。响应时间是指完成
在一个大型的数据库中，性能成为人们关注的焦点之一，如何让数据库高效有效的运行成为广大数据库管理人员和开发人员必须要考虑的问题。性能是一个应用或多个应用在相同的环境下运行时对效率的衡量。性能常用响应时间和工作效率来表示。响应时间是指完成一个任务花费的时间，可以从以下三方面来减少响应时间：
・ 减少竞争和等待的次数，尤其是磁盘读写等待次数
・ 利用更快的部件
・ 减少利用资源所需的时间
绝大多数性能的获得来自于优秀的数据库设计、精确的查询分析和适当的索引。最好性能的获得能够通过确立优秀的数据库设计，在开发时学会使用SQL Server查询优化器来实现。
为了取得更好的数据库性能，我们就需要对数据库进行优化，减少系统资源的竞争，如对数据cache，过程cache，系统资源和CPU的竞争。
在SQL Server中，有如下优化层次：
・应用层――大部分性能的获得来自于对你的SQL应用中查询的优化，这必须是以好的数据库设计为基础的。
・数据库层――应用共享在数据库层中的资源，这些资源包括硬盘，事务日志和数据cache。
・服务器层――在服务器层有许多共享的资源，包括数据高速缓存，过程高速缓存，锁，CPU等。
・设备层――指的是存储数据的磁盘及其控制器，在这一层，你应尤其关注磁盘的I/O。
・网络层――指连接用户和SQL Server的网络。
・硬件层――指可利用的CPU。
・操作系统层――理想地，SQL Server是一台机器的唯一主要应用，它必须和操作系统以及其他sybase软件，如Backup Server或SQL Server Monitor共享处理器、内存以及其他资源。
在大多数情况下面，我们是对应用层进行优化，，因为对应用性能的优化是大家最乐于接受的功能，其结果能被观测及检验，查询的性能是SQL应用的整个性能的一个关键。
应用层上的问题包括以下内容：
・决策支持VS.和在线事务处理(OLTP)需要不同的性能策略
・事务设计能够减少并发，因为长的事务保持占用锁，也就减少了其他用户对相关数据的存取
・关联一致性对数据修改需要join操作
・支持Select操作的索引增加了修改数据的时间
・为了安全而设立的审计限制了性能
在应用层优化的选项包括：
・远程处理或复制处理能够把决策支持从OLTP机器中分离出来
・利用存储过程来减少编译时间和网络的利用
・利用最少量的锁去满足你的应用需要
数据库层的问题包括：
・建立备份和恢复方案
・在设备上分布存储数据
・审计操作影响性能;仅审计你所需的
・日常的维护活动将导致性能的降低和导致用户不能操作数据库表
在数据库层上优化选择包括：
・利用事务日志的阀值来自动转储事务日志防止其超出使用空间
・在数据段中用阀值来监视空间的使用
・利用分区来加速数据的装入
・对象的定位以避免硬盘的竞争
・把重要表和索引放入cache中，保证随时取得
服务器层的问题有：
・应用的类型――服务器是支持OLTP还是DSS，或者两者都支持
・所支持的用户数影响优化决策――随着用户数的增加，对资源的竞争会发生改变
・网络负荷
・当用户数和事务数达到一定的数量时复制服务器或其他分布式处理是一个解决的方法
服务器层的优化的选项包括:
・优化内存――一个关键的配置参数和其他方面的参数
・决策是客户端处理还是服务器端处理――有些处理能在客户端进行吗
・配置cache的大小和I/O的大小
・增加多个CPU
・为空闲时间排定批处理任务和生成报表
・工作负荷发生改变，重新配置特定参数
・决定是否可能把DSS移到另一个SQL服务器中设备层
设备层的问题包括：
・主设备、包含用户数据库的设备，用户数据设备，或数据库日志是否要镜像
・怎样在设备之间分布系统数据库、用户数据库和数据库日志
・为获得对堆表插入操作的高性能，是否有必要进行分区
设备层上优化的选项包括：
・用多个中等大小的设备及多个控制器可能比用少量的大设备有更好的I/O性能
・分布数据库，表和索引以在不同的设备上进行I/O装载
网络层
实际上，SQL Server的所有用户都是通过网络存取他们的数据，
网络层上的主要问题有:
・网络的流量
・网络的瓶颈
・网络的速度
网络层上优化的选项包括：
・配置包的大小，以使其与应用的需要相匹配
・配置子网
・分隔出繁忙的网络运用
・创建一个高容量的网络
・配置多个网络引擎
・更好地设计应用，限制所需的网络传输
硬件层
在硬件层上的问题包括
・CPU的效率
・磁盘的存取:控制器和磁盘
・磁盘备份
・内存的使用
在硬件层上优化的选项包括：
・增加CPU以适应工作负荷
・配置调度程序以提高CPU利用率
・遵循多处理器应用设计指导以减少竞争
・配置多个数据cache操作系统层
操作系统层的主要问题有：
・文件系统――是否被SQL Server独占使用
・内存管理――精确估算操作系统和其他程序的内存占用
・CPU的利用――整个系统共有多少处理器可用?有多少分配给SQL Server
在操作系统层优化的选项包括：
・网络接口
・在文件和原始分区之间选择
・增加内存
・把客户操作和批处理移到其他机器上
・SQL Server利用多个CPU
(责任编辑：铭铭 mingming_ky@126.com TEL：（010）68476636)
原文转自：www.ltesting.net
篇4：突破瓶颈 数据库性能优化“路线图”
数据交互复杂度与频度的提升，导致了数据库在运维、迁移和规模扩展进程中的性能问题，作为一项确保企业IT基础部件健康运营的关键技术，数据库性能优化的实现路径和IT系统管理架构越来越密不可分。
南方某省级电信运营商的计费业务营账系统在上线运行后不久即出现性能问题。主要问题表现在最终用户的交互响应达不到预期，特别是在业务繁忙时段无法做出及时响应。从主机系统的角度观察，问题主要集中在系统的I/O（输入/输出）等待较大。而该营账系统由业务应用程序、甲骨文数据库、IBM AIX主机、IBM企业级存储服务器等部件构成，性能瓶颈的定位和优化过程均较为复杂。
数据库专家通过应用性能监测工具分析系统运行状况，在对主机和存储系统进行调优、并确保其能够满足现阶段生产系统的处理需求后，对甲骨文数据库的优化提出了针对性的建议。建议包括，为了应用系统扩容后处理压力的增大，对甲骨文数据库的性能参数进行修改；通过监测软件排查资源消耗最大的SQL语句的逻辑设计，将这些SQL语句的表结构与索引分别存储，建立合适的分区索引；通过监测软件对数据库和应用的数据分析，准确定位应用系统运行瓶颈，并做出相应的检查和调整。
这一典型案例浓缩了数据库性能优化过程中的几个关键步骤，及其在整体IT管理流程中的角色定位。在数据库成熟应用的时代，数据库的性能优化已经演变为一项相当严密的系统工程。作为企业IT基础设施的核心部件之一，数据库并不是孤立的系统，它与网络、操作系统、存储等硬件系统紧密相连，这种与其他IT部件的多重连接特性决定了数据库性能优化是一门综合技术。
在应用丛生、高度分布式的环境中，要总结出一套“放之四海皆准”的数据库性能优化方法论并不容易。但结合企业自身特色的性能优化流程却是有据可循的。在流程确立的过程之中，企业首先需要明确的问题就是，无论从什么样的角度切入，都要确保优化行为能够与IT系统的整体管理框架保持协调地联动，因为数据库的性能问题不仅仅局限在数据库内部。在大部分情况下，其优化行为都要围绕IT整体性能调优的思路展开。
路径全局谋划
古语云：“不谋全局者，不足谋一域。”说的是如果不从全局角度考虑问题，是无法获得局部智慧的。具体到数据库性能优化，通常包含针对应用、参数、存储、硬件、网络、操作系统的优化操作。有统计显示，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，只占数据库系统性能提升的40%左右，其余60%的系统性能提升则来自于对应用程序的优化。作为金融、电信行业的资深数据库顾问，庄梁科技(北京)有限公司数据库专家牛新庄博士指出，数据库性能优化在很多时候都需要解决数据库以外的问题，这要求实践者具有完整的知识体系，是一项非常具有挑战性的工作。
“系统资源紧张是导致数据库性能问题的根本原因。”牛新庄博士说。针对常见的来自CPU、内存、磁盘I/O、网络的系统资源损耗，他总结了一套常规的问题流程。具体包含定位性能瓶颈、判断最消耗资源的应用或SQL，对逻辑资源的重新划分、、分析性能问题是否局限于数据库、追溯问题原因等步骤。
在阐述数据库性能优化的整体性时，海关数据库专家王翔强调，单点调优对数据库性能的提升意义不大。他指出，在针对常见的分布式数据库引擎的优化过程中，DBA（数据库管理员）的主要任务包括网络、架构、存储的调优和业务应用的优化，除此之外，还有通常被IT部门所忽视的用户体验的优化。“数据库性能优化存在很多程式化的内容，每一个的DBA都有自己解决问题的套路，而这些套路的共同点是从全局角度出发实施具体操作。”王翔说。
现阶段，用户反馈和运行监控是DBA发现数据库性能问题的主要来源。发现故障后，DBA需要用手动指令或专业的监控分析软件排查系统故障点，并确定合理的性能优化步骤。其基本的指导原则为，通过尽可能少的磁盘访问获取所需要的数据（常规的调优策略如图1所示）。数据库系统外的应用优化通常涉及源代码和SQL语句的调整。比较而言，源代码修改存在较高的时间成本，同时可获得的性能提升收益有限；由于应用程序对数据库的操作通常最终表现为SQL语句对数据库的操作，因此SQL语句的优化能够以提升SQL执行效率的方式实现数据库性能的提升。
图1：数据库性能优化常规策略
每个DBA眼中都有一条数据库最佳优化路径。而企业间IT应用的天然差异是导致这一结果的根本原因。同时，数据库性能优化方法还具有浓重的行业色彩。“银行的数据库应用以短交易为主，即主要涉及银行内部的固定数据处理流程，数据库优化主要以集成式优化操作为主；而税务行业的主营业务以长交易为主，一些审批流程需要在系统外部运转，其数据库故障的定位和优化将与短交易优化操作有所区别。”牛新庄说。
王翔在分析海关数据库应用特色时指出，海关数据库应用主要集中在甲骨文和SQL Server平台，数据处理以短交易为主，强调数据交换能力，但数据总体容量不如金融、电信等行业，同时数据交换以内部为主，不存在大量用户基础对数据库系统的访问。围绕这些特性，在实际的操作中，海关IT部门的数据库性能优化操作主要围绕基于快照、单双向复制的集成式优化展开。应用优化方面，主要涉及数据库参数的合理配置、数据库端缓冲调整，以及对频繁调用应用服务的打包处理。王翔介绍，中国海关专门成立了IT优化小组，负责制定和执行包括数据库在内的IT整体优化策略。
而在行业应用内部，不同系统对数据库性能的要求也不尽相同。以电信应用为例，某省级电信公司就从实际需要出发，将计费系统和销账系统分离，各自独立承载不同的数据处理任务。之所以进行这样的划分，是由于承载原始话单采集计费系统的特点表现在用户数少、数据库连接数少，数据存储量大，磁盘I/O高，但对响应时间的要求不高；而负责缴费的销账系统面对的是柜台营业员和电信用户，用户数量多，数据库连接数量大，但数据存储量和磁盘I/O都相比计费系统小得多，同时对系统响应时间要求高，要做到不超过3秒的时间响应。考虑到两种应用对数据库资源的需求存在很大差异，采用一个数据库会导致容量过大和管理不利，而I/O数据量过大时可直接降低响应时间。出于保证应用可靠性和系统安全的需要，该电信用户最终决定在设计时对两种功能的支持系统进行了明确划分。
谈到不同品牌的数据库优化流程是否存在差异的问题时，牛新庄和王翔两位数据库专家均表示，主流关系型数据库的优化基本遵循固定的流程。在具体的操作过程中，都是通过分析数据库对CPU、内存、磁盘I/O和网络的占用情况，与具体的应用相结合做出最终的性能瓶颈定位。但是，不同类型数据库的优化则会体现出明显的差异性。王翔指出，关系型数据库和XML数据库在数据库参数配置时就会涉及完全不同的技术细节。“关系型数据库的优化主要涉及索引的合理使用、I/O改造等内容，而XML数据库的磁盘I/O表现不同，数据存储以大字段为主，与应用的结合更为紧密。针对XML特性，DBA需要运用介于数据仓库和关系型数据库之间的数据库参数进行调整。”王翔说。
设计规避风险
和其他IT基础组件一样，数据库性能下降很大一部分的风险是能够在数据库的设计阶段予以规避的。因此，设计优化也就成为了数据库性能优化技术的源头和方向，
牛新庄指出，目前企业的数据库应用普遍表现出对设计阶段优化的忽视。根据多年的行业服务经验，他表示，企业对设计优化的不够重视主要体现在，工期紧张，开发时间短，以及系统匆忙上线后未经过充分优化和测试。“数据库逻辑结构的不合理、索引设计不合理，开发阶段的技术冲突无法调适，多种因素的累积作用导致了许多数据库系统上线后不久即出现性能故障”牛新庄说。
完整的数据库性能优化周期可以分为两个阶段，一是设计与开发阶段，主要负责对数据库逻辑和物理结构的优化设计，使其在满足具体业务需求的前提下，系统性能达到最佳，同时系统开销最小；二是数据库的运行阶段，其优化手段以数据库级、操作系统级、网络级为主。比较生命周期的调优成本与调优收益曲线，我们发现性能调优的成本随软件生命周期进程而增加，但调优收益却随软件生命周期进程而减少。由此可见，数据库上线之前的早期测试和调优工作不仅是日后数据库健康运维的基础，同时也可以有效避免那些应用后期不必要或需要付出高昂代价的优化操作。
为了减少因为数据库“被动”设计而导致的性能问题，王翔所在中国海关信息中心采用了DBA主动参与项目设计评审过程的方法，及早找出数据库的设计缺陷。项目协作方面，数据库专家还会与存储专家共同规划统一集中式存储架构，依据主干业务、其他业务等应用职能对数据库应用结构进行分割，并参与确立IT基础设施的备份、监控流程，力求将数据库的存储问题、物理布局等问题“消灭”在项目设计阶段。
术业有专攻
利器善事。数据库性能优化不能缺少有着丰富经验和严密知识体系的数据库专家，同样不能缺少完整的数据库性能保障框架和专业化的优化工具。伴随着关系型数据库三十余年的稳定发展，数据库性能优化已经成为商业IT管理软件供应商繁衍生息的乐土。老牌系统管理软件厂商BMC和CA都拥有数据库优化的产品工具；同时，这一领域还催生出很多以数据库优化为主营业务的软件公司，例如分布式数据库优化的领导者Quest Software、应用性能管理厂商Precise（被VERITAS公司以6亿美元的价格收购，并随VERITAS被赛门铁克连环收购，其i3产品系列并入赛门铁克旗下），以及提供图形化异构数据库管理工具厂商Embarcadero（相关产品及关键特性如附表所示）等。与此同时，数据库原厂商也向用户提供相关的优化工具。
“专业优化工具可以改变黑箱操作模式，为DBA呈现一张数据库实时运行状态的全息图。” Quest虹天软件（北京）有限公司高级经理田三稳说。据介绍，Quest Software的数据库优化工具Quest Central可支持甲骨文、DB2、SQL Server和MySQL平台, 能够快速诊断和解决多种数据库性能问题。通过直观的图形化用户界面，可以快速定位性能瓶颈，追溯问题根源，针对应用过程对最常见的SQL问题进行优化。Quest Central提供的自动化SQL优化机制，可以在不执行应用的前提下，通过代码扫描找出低效率查询并加以优化，消除SQL语句中的性能瓶颈。而待优化语句还会被自动重写为备份语句供DBA调整使用。
从甲骨文数据库优化起家的Quest Software，已经将其数据库性能优化产品扩展到多种关系型数据库平台。谈到以Quest为代表的专业优化软件的优势，田三稳表示，原厂商工具的局限性体现在缺乏跨平台的监控和诊断能力，而跨平台的数据库应用优化恰恰是企业的普遍需求。他坦言Quest Software正面临着来自原厂商工具的竞争。“随着甲骨文数据库的不断升级，它所附带的优化工具也开始提供一些与我们类似的功能，同时价格更低，但我们的优势是对跨平台数据库环境的透明支持，我们为客户提供了搭建集成化通用数据库性能优化平台的技术和方案”他说。他同时强调，与同类厂商相比，Quest Software的特色之处包括，具有亲和力的图形化诊断界面、独特的表空间重组技术、完善的底层专家知识库、自动化SQL优化以及对系统性能的实时诊断能力。
Quest Software拥有自己的数据库性能优化方法论，由监控、诊断和问题解决三个连贯的环节所构成，在兼容用户个性化管理需求的同时，可以为客户构建集中式、跨平台的数据库管理解决方案。目前，其优化工具已经在北京移动、上海移动、北京地税、北京电力、山西网通、海关总署、中国工商银行、东芝复印机等客户环境中得到部署。
一线数据库专家对专业优化软件持有自己的看法。牛新庄就指出，这些软件的主要功能是监控，能够定位问题却不能进行调整，当最后发现性能故障与应用或数据库设计有关后，还是需要DBA做出手工调整。在现阶段，市场上的专用软件仍无法替代数据库专家手中基于脚本的定制优化工具；海关的王翔则表示仍然习惯于脚本操作方式，大部分的数据库并没有安装图形化管理界面。“甲骨文的Web监控工具在实际的操作中还是不够实用，对于DBA来说，管理工具越轻量级约好。”王翔说。而很多DBA没有采用专用软件还有一个原因，就是在系统宕机时，这些工具是无法使用的，DBA必须通过脚本语句查看数据库内部状况。
针对DBA对手工操作和脚本方式的偏爱，田三稳表示，专用工具的很大一部分价值体现在对性能故障的预见和主动管理能力，以Quest Software工具为例，它既提供事先预警机制，还提供实时诊断、历史回放和性能参数的分析报告功能。“数据库高手可以凭经验或编写脚本来解决问题，但大部分中小企业的DBA并不具备这样的能力。Quest可以为这些企业提供一个功能齐全、使用方便的数据库监控管理平台，帮助他们建立起性能管理机制。”他说。他同时指出，一些企业具有非常高的IT审计要求，限制使用手工编写管理脚本或对数据库进行修改，这时专业工具的优势就显现出来。另外，在发现空间问题、空间重组和容量规划等数据库存储优化领域，Quest等工具也具备预防性维护和问题预测的能力。
经验、工具和全局观是做好数据库性能优化必不可少的三要素。今天的数据库性能优化不再是一个狭义的话题，当我们越来越深入其中，就会发现其覆盖了相当广阔的技术和管理领域。数据库应用的复杂性决定了DBA智慧和专用工具的协同作战将成为未来应用的方向，而作为一个垂直的优化流程，数据库性能优化将与新一代的IT管理框架实现更加透彻和更深层次的融合。
编看编想
这是个不断变化的话题，因为在IT应用快速进化的今天，数据库的职能和在IT系统架构中的角色定位在不停地变化着。这是我们仍会感觉这个话题如此鲜活而又充满探索可能的原因。
对每个DBA而言，这个话题所覆盖的庞大技术疆域都是极具诱人和挑战性的。在经验和专用工具之间，DBA们需要找到一条能够最快速发现问题和解决问题的路线图。必须承认，我们真的很难为这种处在不断变化中的技术应用绘制一幅“百战百胜”的路线图，但是可以针对可能出现的数据库故障建立相对固化的处理流程。所以，在DBA的脑海中，这幅路线图不一定有多么清晰或严谨，但它必须能够在你遇到问题时指引你该如何行动。
从某种意义上说，数据库性能优化是一项没有尽头的任务，因为用户对数据库性能的要求没有止境。在SOA时代，这一切会改变吗？很难预测重大架构变革所引发的具体技术的联动效应，但可以肯定的是，SOA框架下的数据库性能优化所面对的挑战比今天毫不逊色。王翔表示，SOA所强调服务自治性，是原有性能调优技术非常适用的；而在SOA的交互方面，应用对于服务编排和XML数据处理在交互过程中的重要性将进一步凸现，DBA需要根据应用“补补课”。
当数据库变身为数据服务，在成为独立服务的同时还要服务于众多的服务节点，这种超越以往的应用复杂性要求DBA刷新自己的知识体系、专用工具提供的管理功能更加精细化，同时也要求实践者在这个前所未有的开阔视野下，从崭新的战略全局观突破性能瓶颈。
数据库性能优化工具概览
篇5：SQL Server数据库性能优化数据库教程
server|数据|数据库|性能|优化
设计1个应用系统似乎并不难，但是要想使系统达到最优化的性能并不是一件容易的事，SQL Server数据库性能优化数据库教程
。在开发工具、数据库设计、应用程序的结构、查询设计、接口选择等方面有多种选择，这取决于特定的应用需求以及开发队伍的技能。本文以SQL Server为例，从后台数据库的角度讨论应用程序性能优化技巧，并且给出了一些有益的建议。1 数据库设计
要在良好的SQL Server方案中实现最优的性能，最关键的是要有1个很好的数据库设计方案。在实际工作中，许多SQL Server方案往往是由于数据库设计得不好导致性能很差。所以，要实现良好的数据库设计就必须考虑这些问题。
1.1 逻辑库规范化问题
一般来说，逻辑数据库设计会满足规范化的前3级标准:
1.第1规范:没有重复的组或多值的列。
2.第2规范:每个非关键字段必须依赖于主关键字，不能依赖于1个组合式主关键字的某些组成部分。
3.第3规范:1个非关键字段不能依赖于另1个非关键字段。
遵守这些规则的设计会产生较少的列和更多的表，因而也就减少了数据冗余，也减少了用于存储数据的页。但表关系也许需要通过复杂的合并来处理，这样会降低系统的性能。某种程度上的非规范化可以改善系统的性能，非规范化过程可以根据性能方面不同的考虑用多种不同的方法进行，但以下方法经实践验证往往能提高性能。
1.如果规范化设计产生了许多4路或更多路合并关系，就可以考虑在数据库实体(表)中加入重复属性(列)。
2.常用的计算字段(如总计、最大值等)可以考虑存储到数据库实体中。
比如某一个项目的计划管理系统中有计划表，其字段为:项目编号、年初计划、二次计划、调整计划、补列计划…，而计划总数(年初计划+二次计划+调整计划+补列计划)是用户经常需要在查询和报表中用到的，在表的记录量很大时，有必要把计划总数作为1个独立的字段加入到表中。这里可以采用触发器以在客户端保持数据的一致性。
3.重新定义实体以减少外部属性数据或行数据的开支。相应的非规范化类型是:
(1)把1个实体(表)分割成2个表(把所有的属性分成2组)。这样就把频繁被访问的数据同较少被访问的数据分开了。这种方法要求在每个表中复制首要关键字。这样产生的设计有利于并行处理，并将产生列数较少的表。
(2)把1个实体(表)分割成2个表(把所有的行分成2组)。这种方法适用于那些将包含大量数据的实体(表)。在应用中常要保留历史记录，但是历史记录很少用到。因此可以把频繁被访问的数据同较少被访问的历史数据分开。而且如果数据行是作为子集被逻辑工作组(部门、销售分区、地理区域等)访问的，那么这种方法也是很有好处的。
1.2 生成物理数据库
要想正确选择基本物理实现策略，必须懂得数据库访问格式和硬件资源的操作特点，主要是内存和磁盘子系统I/O。这是一个范围广泛的话题，但以下的准则可能会有所帮助。
1.与每个表列相关的数据类型应该反映数据所需的最小存储空间，特别是对于被索引的列更是如此。比如能使用smallint类型就不要用integer类型，这样索引字段可以被更快地读取，而且可以在1个数据页上放置更多的数据行，因而也就减少了I/O操作。
2.把1个表放在某个物理设备上，再通过SQL Server段把它的不分簇索引放在1个不同的物理设备上，这样能提高性能。尤其是系统采用了多个智能型磁盘控制器和数据分离技术的情况下，这样做的好处更加明显。
3.用SQL Server段把一个频繁使用的大表分割开，并放在2个单独的智能型磁盘控制器的数据库设备上，这样也可以提高性能。因为有多个磁头在查找，所以数据分离也能提高性能。
4.用SQL Server段把文本或图像列的数据存放在1个单独的物理设备上可以提高性能。1个专用的智能型的控制器能进一步提高性能。
2 与SQL Server相关的硬件系统
与SQL Server有关的硬件设计包括系统处理器、内存、磁盘子系统和网络，这4个部分基本上构成了硬件平台，Windows NT和SQL Server运行于其上。
2.1 系统处理器(CPU)
根据自己的具体需要确定CPU结构的过程就是估计在硬件平台上占用CPU的工作量的过程。从以往的经验看，CPU配置最少应是1个80586/100处理器。如果只有2～3个用户，这就足够了，但如果打算支持更多的用户和关键应用，推荐采用Pentium Pro或PⅡ级CPU。
2.2 内存(RAM)
为SQL Server方案确定合适的内存设置对于实现良好的性能是至关重要的。SQL Server用内存做过程缓存、数据和索引项缓存、静态服务器开支和设置开支。SQL Server最多能利用2GB虚拟内存，这也是最大的设置值。还有一点必须考虑的是Windows NT和它的所有相关的服务也要占用内存。
Windows NT为每个WIN32应用程序提供了4GB的虚拟地址空间。这个虚拟地址空间由Windows NT虚拟内存管理器(VMM)映射到物理内存上，在某些硬件平台上可以达到4GB。SQL Server应用程序只知道虚拟地址，所以不能直接访问物理内存，这个访问是由VMM控制的。Windows NT允许产生超出可用的物理内存的虚拟地址空间，这样当给SQL Server分配的虚拟内存多于可用的物理内存时，会降低SQL Server的性能。
这些地址空间是专门为SQL Server系统设置的，所以如果在同一硬件平台上还有其它软件(如文件和打印共享，应用程序服务等)在运行，那么应该考虑到它们也占用一部分内存。一般来说硬件平台至少要配置32MB的内存，其中，Windows NT至少要占用16MB。1个简单的法则是，给每一个并发的用户增加100KB的内存。例如，如果有100个并发的用户，则至少需要32MB+100用户*100KB=42MB内存，实际的使用数量还需要根据运行的实际情况调整。可以说，提高内存是提高系统性能的最经济的途径。
2.3 磁盘子系统
设计1个好的磁盘I/O系统是实现良好的SQL Server方案的一个很重要的方面。这里讨论的磁盘子系统至少有1个磁盘控制设备和1个或多个硬盘单元，还有对磁盘设置和文件系统的考虑。智能型SCSI-2磁盘控制器或磁盘组控制器是不错的选择，其特点如下:
(1)控制器高速缓存。
(2)总线主板上有处理器，可以减少对系统CPU的中断。
(3)异步读写支持。
(4)32位RAID支持。
(5)快速SCSI―2驱动。
(6)超前读高速缓存(至少1个磁道)。
3 检索策略
在精心选择了硬件平台，又实现了1个良好的数据库方案，并且具备了用户需求和应用方面的知识后，现在应该设计查询和索引了。有2个方面对于在SQL Server上取得良好的查询和索引性能是十分重要的，第1是根据SQL Server优化器方面的知识生成查询和索引;第2是利用SQL Server的性能特点，加强数据访问操作，
3.1 SQL Server优化器
Microsoft SQL Server数据库内核用1个基于费用的查询优化器自动优化向SQL提交的数据查询操作。数据操作查询是指支持SQL关键字WHERE或HAVING的查询，如SELECT、DELETE和UPDATE。基于费用的查询优化器根据统计信息产生子句的费用估算。
了解优化器数据处理过程的简单方法是检测SHOWPLAN命令的输出结果。如果用基于字符的工具(例如isql)，可以通过键入SHOW SHOWPLAN ON来得到SHOWPLAN命令的输出。如果使用图形化查询，比如SQL Enterprise Manager中的查询工具或isql/w，可以设定配置选项来提供这一信息。
SQL Server的优化通过3个阶段完成:查询分析、索引选择、合并选择。
1.查询分析
在查询分析阶段，SQL Server优化器查看每一个由正规查询树代表的子句，并判断它是否能被优化。SQL Server一般会尽量优化那些限制扫描的子句。例如，搜索和/或合并子句。但是不是所有合法的SQL语法都可以分成可优化的子句，如含有SQL不等关系符“”的子句。因为“”是1个排斥性的操作符，而不是1个包括性的操作符，所在扫描整个表之前无法确定子句的选择范围会有多大。当1个关系型查询中含有不可优化的子句时，执行计划用表扫描来访问查询的这个部分，对于查询树中可优化的SQL Server子句，则由优化器执行索引选择。
2.索引选择
对于每个可优化的子句，优化器都查看数据库系统表，以确定是否有相关的索引能用于访问数据。只有当索引中的列的1个前缀与查询子句中的列完全匹配时，这个索引才被认为是有用的。因为索引是根据列的顺序构造的，所以要求匹配是精确的匹配。对于分簇索引，原来的数据也是根据索引列顺序排序的。想用索引的次要列访问数据，就像想在电话本中查找所有姓为某个姓氏的条目一样，排序基本上没有什么用，因为你还是得查看每一行以确定它是否符合条件。如果1个子句有可用的索引，那么优化器就会为它确定选择性。
所以在设计过程中，要根据查询设计准则仔细检查所有的查询，以查询的优化特点为基础设计索引。
(1)比较窄的索引具有比较高的效率。对于比较窄的索引来说，每页上能存放较多的索引行，而且索引的级别也较少。所以，缓存中能放置更多的索引页，这样也减少了I/O操作。
(2)SQL Server优化器能分析大量的索引和合并可能性。所以与较少的宽索引相比，较多的窄索引能向优化器提供更多的选择。但是不要保留不必要的索引，因为它们将增加存储和维护的开支。对于复合索引、组合索引或多列索引，SQL Server优化器只保留最重要的列的分布统计信息，这样，索引的第1列应该有很大的选择性。
(3)表上的索引过多会影响UPDATE、INSERT和DELETE的性能，因为所有的索引都必须做相应的调整。另外，所有的分页操作都被记录在日志中，这也会增加I/O操作。
(4)对1个经常被更新的列建立索引，会严重影响性能。
(5)由于存储开支和I/O操作方面的原因，较小的自组索引比较大的索引性能更好一些。但它的缺点是要维护自组的列。
(6)尽量分析出每一个重要查询的使用频度，这样可以找出使用最多的索引，然后可以先对这些索引进行适当的优化。
(7)查询中的WHERE子句中的任何列都很可能是个索引列，因为优化器重点处理这个子句。
(8)对小于1个范围的小型表进行索引是不划算的，因为对于小表来说表扫描往往更快而且费用低。
(9)与“ORDER BY”或“GROUP BY”一起使用的列一般适于做分族索引。如果“ORDER BY”命令中用到的列上有分簇索引，那么就不会再生成1个工作表了，因为行已经排序了。“GROUP BY”命令则一定产生1个工作表。
(10)分簇索引不应该构造在经常变化的列上，因为这会引起整行的移动。在实现大型交易处理系统时，尤其要注意这一点，因为这些系统中数据往往是频繁变化的。
3.合并选择
当索引选择结束，并且所有的子句都有了一个基于它们的访问计划的处理费用时，优化器开始执行合并选择。合并选择被用来找出一个用于合并子句访问计划的有效顺序。为了做到这一点，优化器比较子句的不同排序，然后选出从物理磁盘I/O的角度看处理费用最低的合并计划。因为子句组合的数量会随着查询的复杂度极快地增长，SQL Server查询优化器使用树剪枝技术来尽量减少这些比较所带来的开支。当这个合并选择阶段结束时，SQL Server查询优化器已经生成了1个基于费用的查询执行计划，这个计划充分利用了可用的索引，并以最小的系统开支和良好的执行性能访问原来的数据。
3.2 高效的查询选择
从以上查询优化的3个阶段不难看出，设计出物理I/O和逻辑I/O最少的方案并掌握好处理器时间和I/O时间的平衡，是高效查询设计的主要目标。也就是说，希望设计出这样的查询:充分利用索引、磁盘读写最少、最高效地利用了内存和CPU资源。
以下建议是从SQL Server优化器的优化策略中总结出来的，对于设计高效的查询是很有帮助的。
1.如果有独特的索引，那么带有“=”操作符的WHERE子句性能最好，其次是封闭的区间(范围)，再其次是开放的区间。
2.从数据库访问的角度看，含有不连续连接词(OR和IN)的WHERE子句一般来说性能不会太好。所以，优化器可能会采用R策略，这种策略会生成1个工作表，其中含有每个可能匹配的执行的标识符，优化器把这些行标志符(页号和行号)看做是指向1个表中匹配的行的“动态索引”。优化器只需扫描工作表，取出每一个行标志符，再从数据表中取得相应的行，所以R策略的代价是生成工作表。
3.包含NOT、、或! =的WHERE子句对于优化器的索引选择来说没有什么用处。因为这样的子句是排斥性的，而不是包括性的，所以在扫描整个原来数据表之前无法确定子句的选择性。
4.限制数据转换和串操作，优化器一般不会根据WHERE子句中的表达式和数据转换式生成索引选择。例如:
paycheck * 12>36000 or substring(lastname,1,1)=“L”
如果该表建立了针对paycheck和lastname的索引，就不能利用索引进行优化，可以改写上面的条件表达式为:
paycheck<36000/12 or lastname like “L%”
5.WHERE子句中的本地变量被认为是不被优化器知道和考虑的，例外的情况是定义为储备过程输入参数的变量。
6.如果没有包含合并子句的索引，那么优化器构造1个工作表以存放合并中最小的表中的行。然后再在这个表上构造1个分簇索引以完成一个高效的合并。这种作法的代价是工作表的生成和随后的分族索引的生成，这个过程叫REFORMATTING。 所以应该注意RAM中或磁盘上的数据库tempdb的大小(除了SELECT INTO语句)。另外，如果这些类型的操作是很常见的，那么把tempdb放在RAM中对于提高性能是很有好处的。
4 性能优化的其他考虑
上面列出了影响SQL Server的一些主要因素，实际上远不止这些。操作系统的影响也很大，在Windows NT下，文件系统的选择、网络协议、开启的服务、SQL Server的优先级等选项也不同程度上影响了SQL Server的性能。
影响性能的因素是如此的多，而应用又各不相同，找出1个通用的优化方案是不现实的，在系统开发和维护的过程中必须针对运行的情况，不断加以调整。事实上，绝大部分的优化和调整工作是在与客户端独立的服务器上进行的，因此也是现实可行的。
篇6：SQL Server数据库性能优化技巧
设计1个应用系统似乎并不难，但是要想使系统达到最优化的性能并不是一件容易的事，在开发工具、数据库设计、应用程序的结构、查询设计、接口选择等方面有多种选择，这取决于特定的应用需求以及开发队伍的技能。本文以SQL Server为例，从后台数据库的角度讨论应用程序性能优化技巧，并且给出了一些有益的建议。
1 数据库设计
要在良好的SQL Server方案中实现最优的性能，最关键的是要有1个很好的数据库设计方案。在实际工作中，许多SQL Server方案往往是由于数据库设计得不好导致性能很差。所以，要实现良好的数据库设计就必须考虑这些问题。
1.1 逻辑库规范化问题
一般来说，逻辑数据库设计会满足规范化的前3级标准：
1.第1规范：没有重复的组或多值的列。
2.第2规范：每个非关键字段必须依赖于主关键字，不能依赖于1个组合式主关键字的某些组成部分。
3.第3规范：1个非关键字段不能依赖于另1个非关键字段。
遵守这些规则的设计会产生较少的列和更多的表，因而也就减少了数据冗余，也减少了用于存储数据的页。但表关系也许需要通过复杂的合并来处理，这样会降低系统的性能。某种程度上的非规范化可以改善系统的性能，非规范化过程可以根据性能方面不同的考虑用多种不同的方法进行，但以下方法经实践验证往往能提高性能。
1.如果规范化设计产生了许多4路或更多路合并关系，就可以考虑在数据库实体(表)中加入重复属性(列)。
2.常用的计算字段(如总计、最大值等)可以考虑存储到数据库实体中。
比如某一个项目的计划管理系统中有计划表，其字段为：项目编号、年初计划、二次计划、调整计划、补列计划…，而计划总数(年初计划+二次计划+调整计划+补列计划)是用户经常需要在查询和报表中用到的，在表的记录量很大时，有必要把计划总数作为1个独立的字段加入到表中。这里可以采用触发器以在客户端保持数据的一致性。
3.重新定义实体以减少外部属性数据或行数据的开支。相应的非规范化类型是：
(1)把1个实体(表)分割成2个表(把所有的属性分成2组)。这样就把频繁被访问的数据同较少被访问的数据分开了。这种方法要求在每个表中复制首要关键字。这样产生的设计有利于并行处理，并将产生列数较少的表。
(2)把1个实体(表)分割成2个表(把所有的行分成2组)。这种方法适用于那些将包含大量数据的实体(表)。在应用中常要保留历史记录，但是历史记录很少用到。因此可以把频繁被访问的数据同较少被访问的历史数据分开。而且如果数据行是作为子集被逻辑工作组(部门、销售分区、地理区域等)访问的，那么这种方法也是很有好处的。
1.2 生成物理数据库
要想正确选择基本物理实现策略，必须懂得数据库访问格式和硬件资源的操作特点，主要是内存和磁盘子系统I/O。这是一个范围广泛的话题，但以下的准则可能会有所帮助。
1.与每个表列相关的数据类型应该反映数据所需的最小存储空间，特别是对于被索引的列更是如此。比如能使用smallint类型就不要用integer类型，这样索引字段可以被更快地读取，而且可以在1个数据页上放置更多的数据行，因而也就减少了I/O操作。
2.把1个表放在某个物理设备上，再通过SQL Server段把它的不分簇索引放在1个不同的物理设备上，这样能提高性能。尤其是系统采用了多个智能型磁盘控制器和数据分离技术的情况下，这样做的好处更加明显。
3.用SQL Server段把一个频繁使用的大表分割开，并放在2个单独的智能型磁盘控制器的数据库设备上，这样也可以提高性能。因为有多个磁头在查找，所以数据分离也能提高性能。
4.用SQL Server段把文本或图像列的数据存放在1个单独的物理设备上可以提高性能。1个专用的智能型的控制器能进一步提高性能。
2 与SQL Server相关的硬件系统
与SQL Server有关的硬件设计包括系统处理器、内存、磁盘子系统和网络，这4个部分基本上构成了硬件平台，Windows NT和SQL Server运行于其上。
2.1 系统处理器(CPU)
根据自己的具体需要确定CPU结构的过程就是估计在硬件平台上占用CPU的工作量的过程。从以往的经验看，CPU配置最少应是1个80586/100处理器。如果只有2～3个用户，这就足够了，但如果打算支持更多的用户和关键应用，推荐采用Pentium Pro或PⅡ级CPU。
2.2 内存(RAM)
为SQL Server方案确定合适的内存设置对于实现良好的性能是至关重要的。SQL Server用内存做过程缓存、数据和索引项缓存、静态服务器开支和设置开支。SQL Server最多能利用2GB虚拟内存，这也是最大的设置值。还有一点必须考虑的是Windows NT和它的所有相关的服务也要占用内存。
Windows NT为每个WIN32应用程序提供了4GB的虚拟地址空间。这个虚拟地址空间由Windows NT虚拟内存管理器(VMM)映射到物理内存上，在某些硬件平台上可以达到4GB。SQL Server应用程序只知道虚拟地址，所以不能直接访问物理内存，这个访问是由VMM控制的。Windows NT允许产生超出可用的物理内存的虚拟地址空间，这样当给SQL Server分配的虚拟内存多于可用的物理内存时，会降低SQL Server的性能。
这些地址空间是专门为SQL Server系统设置的，所以如果在同一硬件平台上还有其它软件(如文件和打印共享，应用程序服务等)在运行，那么应该考虑到它们也占用一部分内存。一般来说硬件平台至少要配置32MB的内存，其中，Windows NT至少要占用16MB。1个简单的法则是，给每一个并发的用户增加100KB的内存。例如，如果有100个并发的用户，则至少需要32MB+100用户*100KB=42MB内存，实际的使用数量还需要根据运行的实际情况调整。可以说，提高内存是提高系统性能的最经济的途径。
2.3 磁盘子系统
设计1个好的磁盘I/O系统是实现良好的SQL Server方案的一个很重要的方面。这里讨论的磁盘子系统至少有1个磁盘控制设备和1个或多个硬盘单元，还有对磁盘设置和文件系统的考虑。智能型SCSI-2磁盘控制器或磁盘组控制器是不错的选择，其特点如下：
(1)控制器高速缓存。
(2)总线主板上有处理器，可以减少对系统CPU的中断。
(3)异步读写支持。
(4)32位RAID支持。
(5)快速SCSI—2驱动。
(6)超前读高速缓存(至少1个磁道)。
3 检索策略
在精心选择了硬件平台，又实现了1个良好的数据库方案，并且具备了用户需求和应用方面的知识后，现在应该设计查询和索引了。有2个方面对于在SQL Server上取得良好的查询和索引性能是十分重要的，第1是根据SQL Server优化器方面的知识生成查询和索引;第2是利用SQL Server的性能特点，加强数据访问操作。
3.1 SQL Server优化器
Microsoft SQL Server数据库内核用1个基于费用的查询优化器自动优化向SQL提交的数据查询操作，
数据操作查询是指支持SQL关键字WHERE或HAVING的查询，如SELECT、DELETE和UPDATE。基于费用的查询优化器根据统计信息产生子句的费用估算。
了解优化器数据处理过程的简单方法是检测SHOWPLAN命令的输出结果。如果用基于字符的工具(例如isql)，可以通过键入SHOW SHOWPLAN ON来得到SHOWPLAN命令的输出。如果使用图形化查询，比如SQL Enterprise Manager中的查询工具或isql/w，可以设定配置选项来提供这一信息。
SQL Server的优化通过3个阶段完成：查询分析、索引选择、合并选择。
1.查询分析
在查询分析阶段，SQL Server优化器查看每一个由正规查询树代表的子句，并判断它是否能被优化。SQL Server一般会尽量优化那些限制扫描的子句。例如，搜索和/或合并子句。但是不是所有合法的SQL语法都可以分成可优化的子句，如含有SQL不等关系符“”的子句。因为“”是1个排斥性的操作符，而不是1个包括性的操作符，所在扫描整个表之前无法确定子句的选择范围会有多大。当1个关系型查询中含有不可优化的子句时，执行计划用表扫描来访问查询的这个部分，对于查询树中可优化的SQL Server子句，则由优化器执行索引选择。
2.索引选择
对于每个可优化的子句，优化器都查看数据库系统表，以确定是否有相关的索引能用于访问数据。只有当索引中的列的1个前缀与查询子句中的列完全匹配时，这个索引才被认为是有用的。因为索引是根据列的顺序构造的，所以要求匹配是精确的匹配。对于分簇索引，原来的数据也是根据索引列顺序排序的。想用索引的次要列访问数据，就像想在电话本中查找所有姓为某个姓氏的条目一样，排序基本上没有什么用，因为你还是得查看每一行以确定它是否符合条件。如果1个子句有可用的索引，那么优化器就会为它确定选择性。
所以在设计过程中，要根据查询设计准则仔细检查所有的查询，以查询的优化特点为基础设计索引。
(1)比较窄的索引具有比较高的效率。对于比较窄的索引来说，每页上能存放较多的索引行，而且索引的级别也较少。所以，缓存中能放置更多的索引页，这样也减少了I/O操作。
(2)SQL Server优化器能分析大量的索引和合并可能性。所以与较少的宽索引相比，较多的窄索引能向优化器提供更多的选择。但是不要保留不必要的索引，因为它们将增加存储和维护的开支。对于复合索引、组合索引或多列索引，SQL Server优化器只保留最重要的列的分布统计信息，这样，索引的第1列应该有很大的选择性。
(3)表上的索引过多会影响UPDATE、INSERT和DELETE的性能，因为所有的索引都必须做相应的调整。另外，所有的分页操作都被记录在日志中，这也会增加I/O操作。
(4)对1个经常被更新的列建立索引，会严重影响性能。
(5)由于存储开支和I/O操作方面的原因，较小的自组索引比较大的索引性能更好一些。但它的缺点是要维护自组的列。
(6)尽量分析出每一个重要查询的使用频度，这样可以找出使用最多的索引，然后可以先对这些索引进行适当的优化。
(7)查询中的WHERE子句中的任何列都很可能是个索引列，因为优化器重点处理这个子句。
(8)对小于1个范围的小型表进行索引是不划算的，因为对于小表来说表扫描往往更快而且费用低。
(9)与“ORDER BY”或“GROUP BY”一起使用的列一般适于做分族索引。如果“ORDER BY”命令中用到的列上有分簇索引，那么就不会再生成1个工作表了，因为行已经排序了。“GROUP BY”命令则一定产生1个工作表。
(10)分簇索引不应该构造在经常变化的列上，因为这会引起整行的移动。在实现大型交易处理系统时，尤其要注意这一点，因为这些系统中数据往往是频繁变化的。
3.合并选择
当索引选择结束，并且所有的子句都有了一个基于它们的访问计划的处理费用时，优化器开始执行合并选择。合并选择被用来找出一个用于合并子句访问计划的有效顺序。为了做到这一点，优化器比较子句的不同排序，然后选出从物理磁盘I/O的角度看处理费用最低的合并计划。因为子句组合的数量会随着查询的复杂度极快地增长，SQL Server查询优化器使用树剪枝技术来尽量减少这些比较所带来的开支。当这个合并选择阶段结束时，SQL Server查询优化器已经生成了1个基于费用的查询执行计划，这个计划充分利用了可用的索引，并以最小的系统开支和良好的执行性能访问原来的数据。
3.2 高效的查询选择
从以上查询优化的3个阶段不难看出，设计出物理I/O和逻辑I/O最少的方案并掌握好处理器时间和I/O时间的平衡，是高效查询设计的主要目标。也就是说，希望设计出这样的查询：充分利用索引、磁盘读写最少、最高效地利用了内存和CPU资源。
以下建议是从SQL Server优化器的优化策略中总结出来的，对于设计高效的查询是很有帮助的。
1.如果有独特的索引，那么带有“=”操作符的WHERE子句性能最好，其次是封闭的区间(范围)，再其次是开放的区间。
2.从数据库访问的角度看，含有不连续连接词(OR和IN)的WHERE子句一般来说性能不会太好。所以，优化器可能会采用R策略，这种策略会生成1个工作表，其中含有每个可能匹配的执行的标识符，优化器把这些行标志符(页号和行号)看做是指向1个表中匹配的行的“动态索引”。优化器只需扫描工作表，取出每一个行标志符，再从数据表中取得相应的行，所以R策略的代价是生成工作表。
3.包含NOT、、或! =的WHERE子句对于优化器的索引选择来说没有什么用处。因为这样的子句是排斥性的，而不是包括性的，所以在扫描整个原来数据表之前无法确定子句的选择性。
4.限制数据转换和串操作，优化器一般不会根据WHERE子句中的表达式和数据转换式生成索引选择。例如：
paycheck * 12>36000 or substring(lastname,1,1)=“L”
如果该表建立了针对paycheck和lastname的索引，就不能利用索引进行优化，可以改写上面的条件表达式为：
paycheck<36000/12 or lastname like “L%”
5.WHERE子句中的本地变量被认为是不被优化器知道和考虑的，例外的情况是定义为储备过程输入参数的变量。
6.如果没有包含合并子句的索引，那么优化器构造1个工作表以存放合并中最小的表中的行。然后再在这个表上构造1个分簇索引以完成一个高效的合并。这种作法的代价是工作表的生成和随后的分族索引的生成，这个过程叫REFORMATTING。
所以应该注意RAM中或磁盘上的数据库tempdb的大小(除了SELECT INTO语句)。另外，如果这些类型的操作是很常见的，那么把tempdb放在RAM中对于提高性能是很有好处的。
4 性能优化的其他考虑
上面列出了影响SQL Server的一些主要因素，实际上远不止这些。操作系统的影响也很大，在Windows NT下，文件系统的选择、网络协议、开启的服务、SQL Server的优先级等选项也不同程度上影响了SQL Server的性能。影响性能的因素是如此的多，而应用又各不相同，找出1个通用的优化方案是不现实的，在系统开发和维护的过程中必须针对运行的情况，不断加以调整。事实上，绝大部分的优化和调整工作是在与客户端独立的服务器上进行的，因此也是现实可行的。
篇7：SQLServer数据库学习笔记
1，exists和in的理解（参考/article/28922.htm）
exists：如果子查询中包括某一行，那么就为TRUE
in：如果操作数为TRUE等于表达式列表中的一个，那么就为TRUE
exists总是搞得不太明白
select 。。。from。。。where 。。。
where就相当于一个判断条件，只有where后面的表达式运算结果为TRUE，前面的才能select出来
EXISTS用于检查子查询是否至少会返回一行数据，该子查询实际上并不返回任何数据，而是返回值True或False
1: SELECT c.CustomerId, CompanyName 2: FROM Customers c 3: WHERE EXISTS( 4: SELECT OrderID FROM Orders o 5: WHERE o.CustomerID = cu.CustomerID)
像这样的EXISTS子查询中的SELECT什么根本不重要，因为子查询只是检查这个表中有没有满足WHERE后条件的行， 有就返回TRUE，没有就FALSE，所以很多EXISTS后都是SELECT的*
一行行的去判定，EXISTS返回的是TRUE，就是存在，则把这行的相关信息输出
1: select distinct 姓名 from xs 2: where not exists ( 3: select * from kc 4: where not exists ( 5: select * from xs_kc 6: where 学号=xs.学号 and 课程号=kc.课程号 )
分析下上面的查询语句：
把最外层的xs表里的记录一行一行的同中层一行一的笛卡尔乘积后拿到里面去检验
在最里层，如果xs_kc表里的某行有拿来检验的这行的学号，同时有中层拿来检验的课程号
就返回TRUE，说明这个这个学生选了这门课
中层如果某门课程没有收到返回的TRUE信息，说明这个名字和课程的搭配在xs_kc表中没有，或者说中层select出来的是没有被这个学生选择的课程信息，如果有这样的课程，就向最外层返回个TRUE
最外层在返回信息上加了not，即最外层找的是这样的一种学生：
他选择了所有的课程
最外层一行行的去检测，如果他满足这个条件，就输出他的姓名且只输出一次
我这是一层层的分析，还有么有什么别的办法？
2，select。。。into @。。。
和select @。。。 = 。。。应该是相同的吧
3，用AS为列重命名似乎比=更好点，和赋值区分开
4，用compute汇总的时候，如果是根据某列汇总的，先要order by此列，然后在compute相应信息，最后by此列
group或者compute的时候，如果by了某列，select里都要出现相同的列
区别是group的聚合函数在select行中（称为选择列表），而compute的聚合函数在compute行中，同时compute可以不带by，对所有行汇总
[SQLServer数据库学习笔记]
篇8：基于DB2的数据库应用系统的性能优化数据库
引言 DB2 是一种高 性能 的大型关系数据库管理系统，广泛的应用在客户/ 服务器 体系结构中，评价系统性能优化的标准有：吞吐量、响应时间、并行能力等。本文从数据库的设计、查询的优化、并发控制以及客户/服务器模式这四个角度来讨论优化系统性能。 设计数
引言
DB2是一种高性能的大型关系数据库管理系统，广泛的应用在客户/服务器体系结构中。评价系统性能优化的标准有：吞吐量、响应时间、并行能力等。本文从数据库的设计、查询的优化、并发控制以及客户/服务器模式这四个角度来讨论优化系统性能。
设计数据库
1. 熟悉业务系统
对业务系统的熟悉程度对整个数据库系统的性能有很大影响，一个对业务不熟悉的设计人员，尽管有丰富的数据库知识，也很难设计出性能最佳的数据库应用系统。
2. 规范化与非规范化
数据库被规范化后，减少了数据冗余，数据量变小，数据行变窄。这样DB2的每一页可以包括更多行，那么每一区里的数据量更多，从而加速表的扫描，改进了单个表的查询性能。但是，当查询涉及多个表的时候，需要用很多连接操作把信息从各个表中组合在一起，导致更高的CPU和I/O花销。那么，有很多时候需要在规范化和非规范化之间保持平衡，用适当的冗余信息来减少系统开销，用空间代价来换取时间代价。有订单信息表OrderDetail，它里面记录了投递员信息，收款员信息，物品信息，价格策略，客户信息…..这些信息分别在投递员信息表、收款员信息表、物品信息表、价格策略表、客户信息表中存放。如果按照规范化的要求，OrderDetail查询时就必须要与这么多个表进行连接或者嵌套查询。如果OrderDetail表中的数据量是在百万级的，那么一次查询所需要的时间可能会达到好几个小时。事实上，只要在设计时保证数据的逻辑有效性，很多信息都可以直接冗余在OrderDetail表中，这些冗余的数据能够极大的提高查询的效率，从而减少CPU和I/O操作。
3. 数据条带化
如果一个表的记录条数超过一定的规模，那么最基本的查询操作也会受到影响，需要将该表根据日期水平划分,把最近、最经常用的数据和历史的、不经常用的数据划分开来，或是根据地理位置、部门等等进行划分。还有一种划分方式DD垂直划分，即把一个属性列很多的表分割成好几个小表，比如把经常用到的属性放在一个表里，不经常用到的属性放在另一个表里，这样可以加快表的扫描，提高效率。
4. 选择数据类型
对每一属性选择什么样的数据类型很大程度上依据表的要求，但是在不违背表要求的前提下，选择适当的数据类型可以提高系统性能。比如有text列存放一本书的信息，用BLOB而不是character(1024)，BLOB存放的是指针或者文件参照变量，真正的文本信息可以放在数据库之外，从而减少数据库存储空间，使得程序运行的速度提高。DB2提供了UDT（User Defined Datatypes）功能，用户可以根据自己的需要定义自己的数据类型。
5. 选择索引
索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。使用索引可以快速、直接、有序的存取数据。索引的建立虽然加快了查询，另一方面却将低了数据更新的速度，因为新数据不仅要增加到表中，也要增加到索引中。另外，索引还需要额外的磁盘空间和维护开销。因此，要合理使用索引：
●在经常进行连接，但是没有指定为外键的属性列上建立索引。
●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。按索引来排序或分组，可以提高效率。
●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。
●如果待排序的列有多个，可以在这些列上建立复合索引（compound index），即索引由多个字段复合而成。
查询优化
现在的数据库产品在系统查询优化方面已经做得越来越好，但由于用户提交的SQL语句是系统优化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效，因此用户所写语句的优劣至关重要。下面重点说明改善用户查询计划的解决方案。
1． 排序
在很多时候，应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，可以避免排序的步骤，当以下的情况发生时，排序就不能省略：
●索引中不包括一个或几个待排序的列；
●group by或order by子句中列的次序与索引的次序不一样；
●排序的列来自不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表，尽管有时可能影响表的规范化，但相对于效率的提高是值得的，
如果排序不可避免，那么应当试图简化它，如缩小排序列的范围等。
2． 主键
主键用整型会极大的提高查询效率，而字符型的比较开销要比整型的比较开销大很多，用字符型数据作主键会使数据插入、更新与查询的效率降低。数据量小的时候这点降低可能不会被注意，可是当数据量大的时候，小的改进也能够提高系统的响应速度。
3． 嵌套查询
在SQL语言中，一个查询块可以作为另一个查询块中谓词的一个操作数。因此，SQL查询可以层层嵌套。例如在一个大型分布式数据库系统中，有订单表Order、订单信息表OrderDetail，如果需要两表关联查询：
SELECT CreateUserFROM Order WHERE OrderNo IN( SELECT OrderNoFROM OrderDetail WHERE Price=0.5)
在这个查询中，找出报纸单价为0.5元的收订员名单。下层查询返回一组值给上层查询，然后由上层查询块再根据下层块提供的值继续查询。在这种嵌套查询中，对上层查询的每一个值OrderNo，下层查询都要对表OrderDetail进行全部扫描，执行效率显然不会高。在该查询中，有2层嵌套，如果每层都查询1000行，那么这个查询就要查询100万行数据。在系统开销中，对表Order的扫描占82％，对表OrderDetail的搜索占16％。如果我们用连接来代替，即：
SELECT CreateUserFROM Order,OrderDetailWHERE Order.OrderNo=OrderDetail.OrderNo AND Praice=0.5
那么对表Order的扫描占74％，对表OrderDetail的搜索占14％。
而且，一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。
4． 通配符
在SQL语句中，LIKE关键字支持通配符匹配，但这种匹配特别耗费时间。例如：SELECT * FROM Order WHERE CreateUser LIKE ‘M_ _ _’ 。即使在CreateUser字段上建立了索引，在这种情况下也还是采用顺序扫描的方式，Order表中有1000条记录，就需要比较1000次。如果把语句改为SELECT * FROM Order WHERE CreateUser >’M’ AND CreateUser <’N’，在执行查询时就会利用索引来查询，显然会大大提高速度。
5． distinct
使用distinct是为了保证在结果集中不出现重复值，但是distinct会产生一张工作表，并进行排序来删除重复记录，这会大大增加查询和I/O的操作次数。因此应当避免使用distinct关键字。
6． 负逻辑
负逻辑如!=、、not in等，都会导致DB2用表扫描来完成查询。当表较大时，会严重影响系统性能，可以用别的操作来代替。
7． 临时表
使用临时表时数据库会在磁盘中建立相应的数据结构，因为内存的访问速度远远大于外部存储器的访问速度，在复杂查询中使用临时表时，中间结果会被导入到临时表中，这种磁盘操作会大大降低查询效率。另外，在分布式系统中，临时表的使用还会带来多个查询进程之间的同步问题。所以，在进行复杂查询时最好不要使用临时表。
8． 存储过程
DB2中的Stored Procedure Builder可以产生存储过程，运行并测试存储过程。存储过程可以包含巨大而复杂的查询或SQL操作，经过编译后存储在DB2数据库中。用户在多次使用同样的SQL操作时，可以先把这些SQL操作做成存储过程，在需要用到的地方直接引用其名字进行调用。存储过程在第一次执行时建立优化的查询方案，DB2将查询方案保存在高速缓存里，以后调用运行时可以直接从高速缓存执行，省去了优化和编译的阶段，节省了执行时间，从而提高效率和系统利用率。
最优的查询方案按照某些标准选择往往不可行，要根据实际的要求和具体情况，通过比较进行选择。DB2提供的Query Patroller可以对不同的查询方案的查询代价进行比较，通过追踪查询语句，返回查询不同阶段的系统开销，从而作出最佳选择。DB2提供的Performance Monitor也对整个数据库系统的性能进行监控，包括I/O时间、查询次数、排序时间、同步读写时间等等。
数据库系统的并发控制也能影响系统性能。多个用户的同时操作可能导致数据的不一致性，DB2为了防止同时修改造成数据丢失和访问未被提交的数据，以及数据的保护读，采用Lock机制来实现控制。
DB2中可以对表空间、表、表列和索引加锁。锁的粒度越大，锁越简单，开销小，并发度低；粒度小，锁机制复杂，开销大，并发度高。大型系统在并发处理中如果遇到所要分配的资源处于锁定状态，系统会把进程挂起等待。如果一个很耗时的查询操作工作于一个经常使用的表上，此时使用表一级锁，意味着整个系统都要等待你的查询结束以后才能够继续运行。所以在复杂查询中，尽量避免使用表一级锁。如果有这一类的需要该怎么办呢？可以利用视图来解决这一类问题。视图避免了对表的直接操作，同时有能够保证数据库的高效运转。
(责任编辑：铭铭 mingming_ky#126.com TEL：（010）－68476636)
原文转自：www.ltesting.net
篇9：在Windows 下优化Oracle9i性能数据库
一、优化磁盘配置 Oracle是一个磁盘I/O强烈的应用，要确保你恰当地配置磁盘和文件系统： 在磁盘上建立数据文件前首先运行磁盘碎片整理程序 为了安全地整理磁盘碎片，需关闭打开数据文件的实例，并且停止服务，如果你有足够的连续磁盘空间建立数据文件，那么
一、优化磁盘配置
Oracle是一个磁盘I/O强烈的应用，要确保你恰当地配置磁盘和文件系统：
在磁盘上建立数据文件前首先运行磁盘碎片整理程序
为了安全地整理磁盘碎片，需关闭打开数据文件的实例，并且停止服务。如果你有足够的连续磁盘空间建立数据文件，那么你就很容易避免数据文件产生碎片。
不要使用磁盘压缩
Oracle数据文件不支持磁盘压缩。
不要使用磁盘加密
加密象磁盘压缩一样增加了一个处理层降低磁盘读写速度。如果你担心自己的数据可能泄密，就使用dbms_obfuscation包和label security选择性地加密数据的敏感部分。
不要使用超过70%的磁盘空间
剩余的磁盘空间存放系统临时数据和作为磁盘碎片整理程序存放中间数据。
使用RAID
选择硬件RAID超过软件RAID；
带有硬件RAID控制器；
日志文件不要放在RAID 5卷上，因为RAID 5读性能高而写性能差。
把日志文件和归档日志放在与控制文件和数据文件分离的磁盘控制系统。
分离页面交换文件到多个磁盘物理卷
跨越至少两个磁盘建立两个页面文件。你可以建立四个页面文件并在性能上受益，确保所有页面文件的大小之和至少是物理内存的两倍。
二、优化CPU使用和配置
取消屏幕保护
屏幕保护吸取大量的CPU资源而且提供的是对数据库服务器毫无意义的用处，特别要禁止3GL屏幕保护，如果你必须使用屏幕保护就用“空屏幕”减少CPU使用。
把系统配置为应用服务器
运行控制面板的“系统”，在高级选项卡中设置“性能选项”到“后台程序”，这提供优先权给应用程序，象类似Oracle的服务，反对用户在图形用户界面启动一个笨拙的程序，
监视系统中消耗中断的硬件
消耗CPU中断和时间的硬件应该避免使用。通常这样的硬件是便宜的因为它把工作载入CPU，而CPU要处理外围的高级性能的硬件，通常需要注意：
1、支持总线控制的网卡
2、支持DMA而不支持PIO的磁盘控制器
使用性能监视器跟踪处理器对象的%Interrupt Time 计数器数值，和这个计数器的基线和标准，然后监视问题。
3、有利避免中断的方式是使用硬件RAID控制器代替Windows2000支持的软件RAID。
保持最小的安全审计记录
在专用服务器上运行Oracle
Oracle是内存消耗大户，不要在执行下列功能的系统上运行Oracle数据库：
1、主域或备份域控制器（Windows 2000下都称域控制器）
2、文件服务器
3、打印服务器
4、远程访问服务器
5、路由器、代理或防火墙
不要使用花哨的壁纸（如果使用，要尽量减小壁纸文件大小）
禁止非必须的服务
最好禁止系统里非必须的服务，如果时而需要某些服务功能，可将启动类型设置为“手动”，要做到这一点首先同网络管理员验证实际的服务需求：
1、如果你的系统不需要打印机，通常停止这个服务并设置为手动；
2、停止License Logging Service服务除非你对它有特殊要求；
3、不应该使用DHCP服务，并禁止它；
4、不要自动启动你不需要的程序；
检查菜单“开始/程序/启动”里的内容，删除不需要的程序。
共2页: 1 [2] 下一页
原文转自：www.ltesting.net
篇10：sqlserver 如何创建分区表数据库教程
server|sqlserver|创建
该文详细介绍实现分区表的过程以及有助于完成此过程的功能，sqlserver 2005 如何创建分区表数据库教程
。逻辑流程如下：图：创建分区表或索引的步骤
确定是否应为对象分区
虽然分区可以带来众多的好处，但也增加了实现对象的管理费用和复杂性，这可能是得不偿失的。尤其是，您可能不需要为较小的表或目前满足性能和维护要求的表分区。前面提到的销售方案使用分区减轻了移动行和数据的负担，但在决定是否实现分区时，您应考虑您的方案是否存在这种负担。
确定分区键和分区数
如果您正在尝试改善大型数据子集的性能和可管理性，并且已经定义了访问模式，则可以使用范围分区减少数据争用的情况，同时减少只读数据不需要分区时的维护工作。要确定分区数，应先评估您的数据中是否存在逻辑分组和模式。如果您通常一次只处理这些已定义子集中的少数几个，则应定义范围以隔离查询，使其只处理相应的数据（即，只处理特定的分区）。
确定是否应使用多个文件组
为了有助于优化性能和维护，应使用文件组分离数据。文件组的数目一定程度上由硬件资源决定：一般情况下，文件组数最好与分区数相同，并且这些文件组通常位于不同的磁盘上。但是，这主要适用于打算对整个数据集进行分析的系统。如果您有多个 CPU，SQL Server 则可以并行处理多个分区，从而大大缩短处理大量复杂报表和分析的总体时间。这种情况下，可以获得并行处理以及在分区表中移入和移出分区的好处。
创建文件组
如果需要为多个文件放置一个分区表以获得更好的 I/O平衡，则至少需要创建一个文件组。文件组可以由一个或多个文件构成，而每个分区必须映射到一个文件组。一个文件组可以由多个分区使用，但是为了更好地管理数据（例如，为了获得更精确的备份控制），应该对分区表进行设计，以便只有相关数据或逻辑分组的数据位于同一个文件组中。使用 ALTER DATABASE，可以添加逻辑文件组名，然后添加文件。要为 AdventureWorks 数据库创建名为 2003Q3 的文件组，请按以下方式使用 ALTER DATABASE：
ALTER DATABASE AdventureWorks ADD FILEGROUP [2003Q3]
创建文件组后，使用 ALTER DATABASE 将文件添加到该文件组中。
ALTER DATABASE AdventureWorks
ADD FILE
(NAME = N'2003Q3',
FILENAME = N'C:\AdventureWorks\2003Q3.ndf',
SIZE = 5MB,
MAXSIZE = 100MB,
FILEGROWTH = 5MB)
TO FILEGROUP [2003Q3]
通过在 CREATE TABLE 的 ON 子句中指定一个文件组，可以为文件创建一个表。但是，如果表未分区，则不能为多个文件组创建一个表。要为一个文件组创建表，请使用 CREATE TABLE 的 ON 子句。要创建分区表，必须先确定分区的功能机制。进行分区的标准以分区函数的形式从逻辑上与表相分离。此分区函数作为独立于表的定义存在，而这种物理分离将起到帮助作用，因为多个对象都可以使用该分区函数。因此，为表分区的第一步是创建分区函数。
为范围分区创建分区函数
范围分区必须使用边界条件进行定义。而且，即使通过 CHECK 约束对表进行了限制，也不能消除该范围任一边界的值。为了允许定期将数据移入该表，需要创建最后一个空分区。
在范围分区中，首先定义边界点：如果存在五个分区，则定义四个边界点值，并指定每个值是第一个分区的上边界 (LEFT) 还是第二个分区的下边界 (RIGHT)。根据 LEFT 或 RIGHT 指定，始终有一个空分区，因为该分区没有明确定义的边界点。
具体来讲，如果分区函数的第一个值（或边界条件）是 '20001001'，则边界分区中的值将是：
对于 LEFT
第一个分区是所有小于或等于 '20001001' 的数据
第二个分区是所有大于 '20001001' 的数据
对于 RIGHT
第一个分区是所有小于 '20001001' 的数据
第二个分区是所有大于或等于 '20001001' 数据
由于范围分区可能在 datetime 数据中进行定义，因此必须了解其含义。使用datetime具有某种含义：即总是同时指定日期和时间。未定义时间值的日期表示时间部分为“0”的 12:00 A.M。如果将 LEFT 与此类数据结合使用，则日期为 10 月 1 日 12:00 A.M. 的数据将位于第一个分区，而 10 月份的其他数据将位于第二个分区。从逻辑上讲，最好将开始值与 RIGHT 结合使用，而将结束值与 LEFT 结合使用。下面的三个子句将创建逻辑上相同的分区结构：
RANGE LEFT FOR VALUES ('20000930 23:59:59.997',
'20001231 23:59:59.997',
'20010331 23:59:59.997',
'20010630 23:59:59.997')
或
RANGE RIGHT FOR VALUES ('20001001 00:00:00.000', '20010101 00:00:00.000', '20010401 00:00:00.000', '20010701 00:00:00.000')
或
RANGE RIGHT FOR VALUES ('20001001', '20010101', '20010401', '20010701')
注意：此处使用 datetime 数据类型确实增加了一定的复杂性，但您需要确保设置正确的边界情况。请注意使用 RIGHT 的简单性，因为默认时间为 12:00:00.000 A.M。对于 LEFT，复杂性增加是因为 datetime 数据类型具有精度。必须选择 23:59:59.997 的原因在于，datetime 数据无法保证毫秒级别的精度。相反，datetime 数据的精度在 3.33 毫秒内。使用 23:59:59.999 这个确切的时间值是不行的，因为该值将被舍入到最接近的时间值，即第二天的 12:00:00.000 A.M。由于进行了这种舍入，将无法正确定义边界，
对于 datetime 数据，必须对明确提供的毫秒值加倍小心。
注意：分区函数还允许将函数作为分区函数定义的一部分。您可以使用 DATEADD(ms,-3,'20010101')，而不是使用 '20001231 23:59:59.997' 明确定义时间。
要在四个活动分区（每个分区代表一个日历季度）中存储四分之一的 Orders 数据，并创建第五个分区以备将来使用（还是作为占位符，用于在分区表中移入和移出数据），请将 LEFT 分区函数与以下四个边界条件结合使用：
CREATE PARTITION FUNCTION OrderDateRangePFN(datetime)
AS
RANGE LEFT FOR VALUES ('20000930 23:59:59.997',
'20001231 23:59:59.997',
'20010331 23:59:59.997',
'20010630 23:59:59.997')
记住，定义四个边界点将创建五个分区。通过查看以下数据集检查此分区创建的数据集：
边界点 '20000930 23:59:59.997' 作为 LEFT（设置模式）：
最左侧的分区将包含所有小于或等于 '20000930 23:59:59.997' 的值
边界点 '20001231 23:59:59.997'：
第二个分区将包含所有大于 '20000930 23:59:59.997' 但小于或等于 '20001231 23:59:59.997' 的值
边界点 '20010331 23:59:59.997'：
第三个分区将包含所有大于 '20001231 23:59:59.997' 但小于或等于 '20010331 23:59:59.997' 的值
边界点 '20010630 23:59:59.997'：
第四个分区将包含所有大于 '20010331 23:59:59.997' 但小于或等于 '20010630 23:59:59.997' 的值
最后，第五个分区将包含所有大于 '20010630 23:59:59.997' 的值。
创建分区架构
创建分区函数后，必须将其与分区架构相关联，以便将分区定向至特定的文件组。定义分区架构时，即使多个分区位于同一个文件组中，也必须为每个分区指定一个文件组。对于前面创建的范围分区 (OrderDateRangePFN)，存在五个分区；最后一个空分区将在 PRIMARY 文件组中创建。因为此分区永远不包含数据，所以不需要指定特殊的位置。
CREATE PARTITION SCHEME OrderDatePScheme
AS
PARTITION OrderDateRangePFN
TO ([2000Q3], [2000Q4], [2001Q1], [2001Q2], [PRIMARY])
注意：如果所有分区都位于同一个文件组中，则可以使用以下更简单的语法：
CREATE PARTITION SCHEME OrderDatePScheme
AS
PARTITION OrderDateRangePFN
ALL TO ([PRIMARY])
创建分区表
定义分区函数（逻辑结构）和分区架构（物理结构）后，即可创建表来利用它们。表定义应使用的架构，而架构又定义函数。要将这三者结合起来，必须指定应该应用分区函数的列。范围分区始终只映射到表中的一列，此列应与分区函数中定义的边界条件的数据类型相匹配。另外，如果表应明确限制数据集（而不是从负无穷大到正无穷大），则还应添加 CHECK 约束。
CREATE TABLE [dbo].[OrdersRange]
(
[PurchaseOrderID] [int] NOT NULL,
[EmployeeID] [int] NULL,
[VendorID] [int] NULL,
[TaxAmt] [money] NULL,
[Freight] [money] NULL,
[SubTotal] [money] NULL,
[Status] [tinyint] NOT NULL ,
[RevisionNumber] [tinyint] NULL ,
[ModifiedDate] [datetime] NULL ,
[ShipMethodID] [tinyint] NULL,
[ShipDate] [datetime] NOT NULL,
[OrderDate] [datetime] NOT NULL
CONSTRAINT OrdersRangeYear
CHECK ([OrderDate] >= '20030701'
AND [OrderDate] <= '20040630 11:59:59.997'),
[TotalDue] [money] NULL
)
ON OrderDatePScheme (OrderDate)
GO
建立索引：是否分区？
默认情况下，分区表中创建的索引也使用相同的分区架构和分区列。如果属于这种情况，索引将与表对齐。尽管未作要求，但将表与其索引对齐可以使管理工作更容易进行，对于滑动窗口方案尤其如此。
例如，要创建唯一的索引，分区列必须是一个关键列；这将确保对相应的分区进行验证，以保证索引的唯一性。因此，如果需要在一列上对表进行分区，而必须在另一个列上创建唯一的索引，这些表和索引将无法对齐。在这种情况下，可以在唯一的列（如果是多列的唯一键，则可以是任一关键列）中对索引进行分区，或者根本就不进行分区。请注意，在分区表中移入和移出数据时，必须删除和创建此索引。
注意：如果您打算使用现有数据加载表并立即在其中添加索引，则通常可以通过以下方式获得更好的性能：先加载到未分区、未建立索引的表中，然后在加载数据后创建分区索引。通过为分区架构定义群集索引，可以在加载数据后更有效地为表分区。这也是为现有表分区的不错方法。要创建与未分区表相同的表并创建与已分区群集索引相同的群集索引，请用一个文件组目标位置替换创建表中的 ON 子句。然后，在加载数据之后为分区架构创建群集索引。
【SQL Server数据库性能优化】相关文章：
5.如何修复SQLSERVER 数据库置疑之(二)数据库教程
6.Android性能优化系列――Understanding Overdraw
7.系统从oracle版本转化为sqlserver版本数据库教程
8.浅析Oracle和SqlServer存储过程的调试、出错处理数据库
10.优化方案
文档为doc格式
