SQL Server数据库性能优化技巧
“棉花娃娃真好玩”通过精心收集，向本站投稿了8篇SQL Server数据库性能优化技巧，以下是小编为大家整理后的SQL Server数据库性能优化技巧，希望对大家有所帮助。
篇1：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个通用的优化方案是不现实的，在系统开发和维护的过程中必须针对运行的情况，不断加以调整。事实上，绝大部分的优化和调整工作是在与客户端独立的服务器上进行的，因此也是现实可行的。
篇2：影响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
篇3：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的工作量的过程
关 键 字：MYSQL
篇4：笔记本电脑性能优化技巧
一、BIOS的优化设置
和普通台式机一样，笔记本电脑的BIOS设置优化是最基本的优化方法，合理设置本本的BIOS，能够加快开机速度，提高内存、CPU、硬盘及显示系统的工作效率，而不同品牌的笔记本电脑的BIOS设置方法也大同小异，一般而言，在BIOS设置中有一个“QuietBoot”选项，这是设置开机画面和开机硬件检测等用的。和台式机一样，默认情况下笔记本电脑开机时首先检测处理器和内存、硬盘等，其中还包括开机画面的显示，而这些工作有时没有必要进行，因此把“QuietBoot”一项设置为“Enabled”，这样就不会显示开机画面及进行硬件检测等步骤了，自然可以大大提高开机启动速度。
目前笔记本电脑的软驱基本上被淘汰出局了，如果你没有使用软驱，又在BIOS里打开了软驱端口，那么每次启动笔记本电脑时都会对软驱进行搜索，这样就减慢了开机速度。我们可以在BIOS中将软驱设置为“None”或“Disabled”(关闭)，同时把第一项开机引导设备设置为“HardDrive”，这样不但加快了开机速度，同时还减少了噪音。
一般来说，在大部分笔记本电脑的BIOS设置里都有一项“SystemDevices”(系统设备)或“Advanced”(高级)选项，在这里可以设置CPU、显卡、内存、硬盘等性能参数。有的笔记本电脑的BIOS中有“DMAChannel”和“VGAFrameBufferSize”两个选项，第一项用于打开IDE设备的DMA传输模式，打开后磁盘性能可以提高很多，而第二个则用来设置显卡的显存大小。对于集成显卡来说，要注意设置技巧，比如集成显卡的显存大小范围为16MB'64MB，则尽量把这个数字设置在64MB以内(如32MB)，如果设置得太高，而总内存容量却很小(如只有128MB)，那么在某些图形软件或游戏动画的渲染中，很有可能出现内存不足导致整体性能大幅度降低，
如果使用独立显卡，在“Advanced”选项中会有“DisplayExpansionSupport”这个选项，把这个选项设成“Disabled”(关闭)后，在分辨率小于1024×768及DOS界面下，会自动缩小画面以保持最佳显示效果。
另外，我们还要把CPU的L2Cache(二级高速缓存)打开，这样有助于CPU的性能发挥，有的笔记本电脑还集成了LAN、Modem、IEEE1394等接口，平时如果不使用这些接口时，最好在BIOS中把这些接口屏蔽掉。
二、CPU的优化使用
我们可以用Powertweak软件来优化本本的CPU和芯片组（下载地址为www.skycn.com/soft/2754.html
如果你是发烧友，也可以对本本的CPU适当超频，当然，笔记本电脑不可能像台式机那样进行“硬”超频。不过我们可以使用SoftFSB这个软件（下载地址为www.newhua.com/soft/10494.htm
优化与超频都可以提高CPU的性能，但在一定程度上加大了CPU的功耗，尽管最新的移动CPU功耗很低，但发热量增加是难免的，因此需要适当考虑降温措施。但是笔记本电脑不方便通过硬件措施来改善散热条件，所以通过软件降温是最为明智的，如果使用的是Win98/WinMe系统，推荐使用WaterfallPro降温软件，该软件安装后会自动启动降温功能，也可以利用新的HTL(节流阀)技术进行降温，缺点是该软件不支持Win/WinXP。而CPUIdle降温软件可在所有的Windows系统下使用，它的下载地址是，该软件运行后会自动对CPU进行降温，并且在CPU信息选项可以看到CPU的全部资料。
篇5：Python性能优化技巧
Python的批评者声称Python性能低效、执行缓慢，但实际上并非如此：尝试以下6个小技巧，可以加快Pytho应用程序，
Python是一门非常酷的语言，因为很少的Python代码可以在短时间内做很多事情，并且，Python很容易就能支持多任务和多重处理。
py
1、关键代码可以依赖于扩展包
Python使许多编程任务变得简单，但是对于很关键的任务并不总是提供最好的性能。使用C、C++或者机器语言扩展包来执行关键任务能极大改善性能。这些包是依赖于平台的，也就是说，你必须使用特定的、与你使用的平台相关的包。简而言之,该解决方案提供了一些应用程序的可移植性,以换取性能,您可以获得只有通过直接向底层主机编程。下面这些扩展包你可以考虑添加到你的个人扩展库中：
Cython
PyInlne
PyPy
Pyrex
这些包有不同的作用和执行方式。例如，Pyrex 让Python处理一些内存任务变得简单高效；PyInline可以直接让你在Python应用程序中使用C代码，虽然内联代码被单独编译，但是如果你能高效的利用C代码，它可以在同一个地方处理每一件事情。
2、使用关键字排序
有很多古老的Python代码在执行时将花费额外的时间去创建一个自定义的排序函数。最好的排序方式是使用关键字和默认的sort方法，看看下面的示例：
代码如下:
import operator
somelist = [(1, 5, 8), (6, 2, 4), (9, 7, 5)]
somelist.sort(key=operator.itemgetter(0))
somelist
#Output = [(1, 5, 8), (6, 2, 4), (9, 7, 5)]
somelist.sort(key=operator.itemgetter(1))
somelist
#Output = [(6, 2, 4), (1, 5, 8), (9, 7, 5)]
somelist.sort(key=operator.itemgetter(2))
somelist
#Output = [(6, 2, 4), (9, 7, 5), (1, 5, 8)],
每一个案例的列表是根据你选择作为关键字参数的索引排序的，这种方式对字符串和数字排序同样适用。
3、优化循环
每一种编程语言都强调循环语句的优化，Python也是一样的。尽管你可以依赖于丰富的技术让循环运行的更快，然而，开发者经常忽略的一个方法是避免在循环内部使用点拼接字符串。对于下面的示例：
代码如下:
lowerlist = [‘this‘, ‘is‘, ‘lowercase‘]
upper = str.upper
upperlist = []
append = upperlist.append
for word in lowerlist:
append(upper(word))
print(upperlist)
#Output = [‘THIS‘, ‘IS‘, ‘LOWERCASE‘]
每一次调用str.upper，Python都会去求这个方法的值，
但是如果你把求值的结果放入一个变量中，就能提高程序的性能。这个关键是减少Python内执行的循环次数,因为Python解析这些实例是比较慢的。
4、使用新版本
任何一个在线上搜索Python资料的人都会发现无数关于Python版本迁移的信息。通常，Python每一个版本都针对之前的一个版本做了优化和改进，以让Python运行的更快。限制因素是你喜欢的函数库是否也针对Python的新版本做了改进。
当你使用了新的函数库，获得了Python的新版本，你需要保证代码依然能够运行，检查应用，修正差异。
然后，如果你仅仅是保证应用能够在新版本上运行，你可能错过新功能的更新。一旦你做了改进，在新版本下配置应用程序，检查问题区域并优先使用新功能更新，对于之前的升级，用户将看到更大性能的提升。
5、尝试多种编程方法
每一次你创建应用的时候，都使用同一种编程方法，在某些情况下降导致程序运行会比预期的慢。在分析的过程中做一些小试验。例如，当管理字典中的数据项时，可以采用安全的方法确定数据项是否已经存在并需要更新它，或者你可以直接添加条目,然后处理项目根本不存在的情况。
代码如下:
n = 16
myDict = {}
for i in range(0, n):
char = ‘abcd‘[i%4]
if char not in myDict:
myDict[char] = 0
myDict[char] += 1
print(myDict)
当myDict是空时，上述的代码通常会运行的更快。但当myDict已经有数据填充时，就有更好的方法可以选择：
代码如下:
n = 16
myDict = {}
for i in range(0, n):
char = ‘abcd‘[i%4]
try:
myDict[char] += 1
except KeyError:
myDict[char] = 1
print(myDict)
两种情况下都输出{‘d‘: 4, ‘c‘: 4, ‘b‘: 4, ‘a‘: 4}，唯一的差异是输出是怎么获得的。站在盒子外考虑和创建新的编程技巧都能让你的程序获得更快的运行速度。
6、交叉编译程序
开发者有时会忘记计算机不能识别任何一种现在应用程序语言，它只识别机器代码。为了运行程序，需要一个应用将人类可读的代码转换成计算机能识别的代码。当用一种语言写程序时，例如Python，然后用另外一种语言来运行它，例如C++，从性能角度看是有道理的。这个取决于你想要用这个应用做什么和主机系统能够提供什么资源。
一个有趣的交叉编译器，Nuitka, 能将Python转换成C++代码，结果是你可以再本机模式下执行应用，而不是依赖于解释器。根据平台和任务中,你可以看到显著的性能提高。
以上就是本文的全部内容了，希望对大家学习Python有所帮助。
篇6：Wordpress数据库优化技巧
WordPress系统使用时间长了，数据库中的冗余数据就会很多，定期优化和清理Wordpress的数据库，可以保证Wordpress能够快速工作，
首先，停用一些无用的插件，将WordPress系统表之外的数据表都删除，只保留wp_posts， wp_comments， wp_terms， wp_term_relationships， wp_term_taxonomy 等系统数据表。
其次，打开phpMyadmin，通过SQL语句进行冗余数据删除操作。删除前记得先备份一下。
删除脚本是：
DELETE FROM wp_posts WHERE post_type = “revision”;
DELETE FROM wp_postmeta. WHERE meta_key = “_edit_lock”;
DELETE FROM wp_postmeta. WHERE meta_key = “_edit_last”;
最后，在phpMyAdmin中，选中所有表，点“优化表”，
经过这一番优化操作，就可以将WordPress数据库中的冗余数据删除，优化了数据库的性能。
以上操作，需要用户懂一些SQL语句，不要进行误操作，如果用户SQL比较熟的话，还可以看看这篇文章《八个有用的WordPress的SQL语句》。
本文自月光博客 [ www.williamlong.info/ ]
篇7：浅析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
篇8：浅析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
【SQL Server数据库性能优化技巧】相关文章：
5.如何修复SQLSERVER 数据库置疑之(二)数据库教程
6.Android性能优化系列――Understanding Overdraw
7.系统从oracle版本转化为sqlserver版本数据库教程
文档为doc格式
