SQL Server数据库的高性能优化经验总结

本文主要向大家介绍的是正确优化SQL

Server数据库的经验总结，其中包括在对其进行优化的实际 *** 作中值得大家注意的地方描述，以及对SQL语句进行优化的最基本原则，以下就是文章的主要内容描述。

优化数据库的注意事项：

1、关键字段建立索引。

2、使用存储过程，它使SQL变得更加灵活和高效。

3、备份数据库和清除垃圾数据。

4、SQL语句语法的优化。(可以用Sybase的SQL

Expert，可惜我没找到unexpired的序列号)

5、清理删除日志。

SQL语句优化的基本原则：

1、使用索引来更快地遍历表。

缺省情况下建立的索引是非群集索引，但有时它并不是最佳的。在非群集索引下，数据在物理上随机存放在数据页上。合理的索引设计要建立在对各种查询的分析和预测上。

一般来说：

①有大量重复值、且经常有范围查询(between,

>,<

，>=,<

=)和order

by、group

by发生的列，可考虑建立群集索引

②经常同时存取多列，且每列都含有重复值可考虑建立组合索引;

③组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。

2、IS

NULL

与

IS

NOT

NULL

不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。任何在where子句中使用is

null或is

not

null的语句优化器是不允许使用索引的。

3、IN和EXISTS

EXISTS要远比IN的效率高。里面关系到full

table

scan和range

scan。几乎将所有的IN *** 作符子查询改写为使用EXISTS的子查询。

4、在海量查询时尽量少用格式转换。

5、当在SQL

SERVER

2000中

如果存储过程只有一个参数，并且是OUTPUT类型的，必须在调用这个存储过程的时候给这个参数一个初始的值，否则会出现调用错误。

6、ORDER

BY和GROPU

BY

使用ORDER

BY和GROUP

BY短语，任何一种索引都有助于SELECT的性能提高。注意如果索引列里面有NULL值，Optimizer将无法优化。

7、任何对列的 *** 作都将导致表扫描，它包括SQL

Server数据库函数、计算表达式等等，查询时要尽可能将 *** 作移至等号右边。

8、IN、OR子句常会使用工作表，使索引失效。如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。

9、SET

SHOWPLAN_ALL>10、谨慎使用游标

在某些必须使用游标的场合，可考虑将符合条件的数据行转入临时表中，再对临时表定义游标进行 *** 作，这样可使性能得到明显提高。

注释：所谓的优化就是WHERE子句利用了索引，不可优化即发生了表扫描或额外开销。经验显示，SQL

Server数据库性能的最大改进得益于逻辑的数据库设计、索引设计和查询设计方面。反过来说，最大的性能问题常常是由其中这些相同方面中的不足引起的。

其实SQL优化的实质就是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索的发生。其实SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会涉及SQL

Server数据库层的资源配置、网络层的流量控制以及 *** 作系统层的总体设计。

在进行软件开发过程中，数据库的使用是非常重要的，但是数据库有很多种，不同数据库的使用方法是不同的。进行软件开发过程中，至少需要掌握一种数据库的使用方法。SQL数据库语法简单、 *** 作方便和高效，是很多人最优的选择，但是SQL语句会受到不同数据库功能的影响，在计算时间和语言的效率上面需要进行优化，根据实际情况进行调整。下面电脑培训为大家介绍SQL数据库的优化方法。

一、适当的索引

索引基本上是一种数据结构，有助于加速整个数据检索过程。唯一索引是创建不重叠的数据列的索引。正确的索引可以更快地访问数据库，但是索引太多或没有索引会导致错误的结果。IT培训认为如果没有索引，处理速度会变得非常慢。

二、仅索引相关数据

指定需要检索数据的精度。使用命令和LIMIT代替SELECT。调整数据库时，必须使用所需的数据集而不是整个数据集，尤其是当数据源非常大时，指定所需的数据集，能够节省大部分时间。

三、根据需求使用或避免临时表

如果代码可以用简单的方式编写，那么永远不要使临时表变得复杂。当然，如果数据具有需要多个查询的特定程序，北大青鸟建议在这种情况下，使用临时表。临时表通常由子查询交替。

四、避免编码循环

避免编码循环是非常重要的，因为它会减慢整个序列的速度。通过使用具有单行的唯一UPDATE或INSERT命令来避免编码循环，并且昌平北大青鸟发现WHERE命令能够确保存储的数据不被更新，这样能够方便在找到匹配和预先存在的数据时被找到。

mysql的优化大的有两方面：

1、配置优化

配置的优化其实包含两个方面的： *** 作系统内核的优化和mysql配置文件的优化

1)系统内核的优化对专用的mysql服务器来说，无非是内存实用、连接数、超时处理、TCP处理等方面的优化，根据自己的硬件配置来进行优化，这里不多讲；

2)mysql配置的优化，一般来说包含：IO处理的常用参数、最大连接数设置、缓存使用参数的设置、慢日志的参数的设置、innodb相关参数的设置等，如果有主从关系在设置主从同步的相关参数即可，网上的相关配置文件很多，大同小异，常用的设置大多修改这些差不多就够用了。

2、sql语句的优化

1、 尽量稍作计算

Mysql的作用是用来存取数据的，不是做计算的，做计算的话可以用其他方法去实现，mysql做计算是很耗资源的。

2尽量少 join

MySQL 的优势在于简单，但这在某些方面其实也是其劣势。MySQL 优化器效率高，但是由于其统计信息的量有限，优化器工作过程出现偏差的可能性也就更多。对于复杂的多表 Join，一方面由于其优化器受限，再者在 Join 这方面所下的功夫还不够，所以性能表现离 Oracle 等关系型数据库前辈还是有一定距离。但如果是简单的单表查询，这一差距就会极小甚至在有些场景下要优于这些数据库前辈。

3尽量少排序

排序 *** 作会消耗较多的 CPU 资源，所以减少排序可以在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL的响应时间。

对于MySQL来说，减少排序有多种办法，比如：

通过利用索引来排序的方式进行优化

减少参与排序的记录条数

非必要不对数据进行排序

数据库的多表大数据查询应如何优化？

1应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

select id from t where num=0

2应尽量避免在 where 子句中使用!=或<> *** 作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。

3应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num=10 or num=20

可以这样查询：

select id from t where num=10

union all

select id from t where num=20

4in 和 not in 也要慎用，因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如：

select id from t where num in(1,2,3)

对于连续的数值，能用 beeen 就不要用 in 了：

select id from t where num beeen 1 and 3

5尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。

见如下例子：

SELECT FROM T1 WHERE NAME LIKE ‘%L%’

SELECT FROM T1 WHERE SUBSTING(NAME,2,1)=’L’

SELECT FROM T1 WHERE NAME LIKE ‘L%’

即使NAME字段建有索引，前两个查询依然无法利用索引完成加快 *** 作，引擎不得不对全表所有数据逐条 *** 作来完成任务。而第三个查询能够使用索引来加快 *** 作。

6必要时强制查询优化器使用某个索引，如在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：

select id from t where num=@num

可以改为强制查询使用索引：

select id from t with(index(索引名)) where num=@num

7应尽量避免在 where 子句中对字段进行表达式 *** 作，这将导致引擎放弃使用索引而进行全表扫描。如：

SELECT FROM T1 WHERE F1/2=100

应改为:

SELECT FROM T1 WHERE F1=1002

SELECT FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=’5378’

应改为:

SELECT FROM RECORD WHERE CARD_NO LIKE ‘5378%’

SELECT member_number, first_name, last_name FROM members

WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21

应改为:

SELECT member_number, first_name, last_name FROM members

WHERE dateofbirth < DATEADD(yy,-21,GETDATE())

即：任何对列的 *** 作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将 *** 作移至等号右边。

8应尽量避免在where子句中对字段进行函数 *** 作，这将导致引擎放弃使用索引而进行全表扫描。如：

select id from t where substring(name,1,3)='abc'--name以abc开头的id

select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id

应改为:

select id from t where name like 'abc%'

select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'

9不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

10在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。

11很多时候用 exists是一个好的选择：

elect num from a where num in(select num from b)

用下面的语句替换：

select num from a where exists(select 1 from b where num=anum)

SELECT SUM(T1C1)FROM T1 WHERE(

(SELECT COUNT()FROM T2 WHERE T2C2=T1C2>0)

SELECT SUM(T1C1) FROM T1WHERE EXISTS(

SELECT FROM T2 WHERE T2C2=T1C2)

两者产生相同的结果，但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。

Java怎么把数据库的数据查询

Statement stmt = null;

ResultSet rs = null;

String query = "select 列名 from 表名 where id=11 and fname='xx' order by 列名 desc limit 1";

stmt = conncreateStatement();

rs = stmtexecuteQuery(query);

if (rsnext()) {

result = rsgetInt("列名");

}

数据库表内数据查询

楼上的 拼写错误，我来修正 ^^

select count() from 表名

如何查询大数据库数据存在

传统数据库处理大数据很困难吧，不建议使用传统数据库来处理大数据。

建议研究下，Hadoop，Hive等，可处理大数据。

如果有预算，可以使用一些商业大数据产品，国内的譬如永洪科技的大数据BI产品，不仅能高性能处理大数据，还可做数据分析。

当然如果是简单的查询，传统数据库如果做好索引，可能可以提高性能。

如何实现不同数据库的数据查询分页

有两种方法

方法1：

select 100 from tbllendlist where fldserialNo not in ( select 300100 fldserialNo from tbllendlist order by fldserialNo ) order by fldserialNo

方法2：

SELECT TOP 100 FROM tbllendlist WHERE (fldserialNo > (SELECT MAX(fldserialNo) FROM (SELECT TOP 300100 fldserialNo FROM tbllendlist ORDER BY fldserialNo) AS T)) ORDER BY fldserialNo

如何提高Oracle数据库数据查询的命中率

影响命中率的因素有四种：字典表活动、临时段活动、回滚段活动、表扫描， 应用DBA可以对这四种因素进行分析，找出数据库命中率低的症结所在。 1)字典表活动 当一个SQL语句第一次到达Oracle内核时数据库对SQL语句进行分析，包含在查询中的数据字典对象被分解，产生SQL执行路径。如果SQL语句指向一个不在SGA中的对象表或视图，Oracle执行SQL语句到数据典中查询有关对象的信息。数据块从数据字典表被读取到SGA的数据缓存中。由于每个数据字典都很小，因此，我们可缓存这些表以提高对这些表的命中率。但是由于数据字典表的数据块在SGA中占据空间，当增加全部的命中率时，它们会降低表数据块的可用空间， 所以若查询所需的时间字典信息已经在SGA缓存中，那么就没有必要递归调用。 2)临时段的活动 当用户执行一个需要排序的查询时，Oracle设法对内存中排序区内的所有行进行排序，排序区的大小由数据库的initora文件的数确定。如果排序区域不够大，数据库就会在排序 *** 作期间开辟临时段。临时段会人为地降低OLTP(online transaction processing）应用命中率,也会降低查询进行排序的性能。如果能在内存中完成全部排序 *** 作，就可以消除向临时段写数据的开销。所以应将SORT_AREA_SIZE设置得足够大，以避免对临时段的需要。这个参数的具体调整方法是:查询相关数据，以确定这个参数的调整。 select from v$sysstat where name='sorts(disk)'or name='sorts(memory); 大部分排序是在内存中进行的，但还有小部分发生在临时段， 需要调整 值，查看initora文件的 SORT_AREA_SIZE值，参数为：SORT_AREA_SIZE＝65536;将其调整到SORT_AREA_SIZE＝131072、这个值调整后，重启ORACLE数据库即可生效。 3)回滚段的活动 回滚段活动分为回滚活动和回滚段头活动。对回滚段头块的访问会降低应用的命中率， 对OLTP系统命中率的影响最大。为确认是否因为回滚段影响了命中率，可以查看监控输出报表中的“数据块相容性读一重写记录应用” 的统计值，这些统计值是用来确定用户从回滚段中访问数据的发生次数。 4)表扫描 通过大扫描读得的块在数据块缓存中不会保持很长时间， 因此表扫描会降低命中率。为了避免不必要的全表扫描，首先是根据需要建立索引，合理的索引设计要建立人对各种查询的分析和预测上，笔者会在SQL优化中详细谈及；其次是将经常用到的表放在内存中，以降低磁盘读写次数。

如何优化数据库提高数据库的效率

1 SQL优化的原则是：将一次 *** 作需要读取的BLOCK数减到最低,即在最短的时间达到最大的数据吞吐量。

调整不良SQL通常可以从以下几点切入：

检查不良的SQL，考虑其写法是否还有可优化内容

检查子查询 考虑SQL子查询是否可以用简单连接的方式进行重新书写

检查优化索引的使用

考虑数据库的优化器

2 避免出现SELECT FROM table 语句，要明确查出的字段。

3 在一个SQL语句中，如果一个where条件过滤的数据库记录越多，定位越准确，则该where条件越应该前移。

4 查询时尽可能使用索引覆盖。即对SELECT的字段建立复合索引，这样查询时只进行索引扫描，不读取数据块。

5 在判断有无符合条件的记录时建议不要用SELECT COUNT （）和select 1 语句。

6 使用内层限定原则，在拼写SQL语句时，将查询条件分解、分类，并尽量在SQL语句的最里层进行限定，以减少数据的处理量。

7 应绝对避免在order by子句中使用表达式。

8 如果需要从关联表读数据，关联的表一般不要超过7个。

9 小心使用 IN 和 OR，需要注意In集合中的数据量。建议集合中的数据不超过200个。

10 <> 用 < 、 > 代替，>用>=代替，<用<=代替，这样可以有效的利用索引。

11 在查询时尽量减少对多余数据的读取包括多余的列与多余的行。

12 对于复合索引要注意，例如在建立复合索引时列的顺序是F1，F2，F3，则在where或order by子句中这些字段出现的顺序要与建立索引时的字段顺序一致，且必须包含第一列。只能是F1或F1，F2或F1，F2，F3。否则不会用到该索引。

13 多表关联查询时，写法必须遵循以下原则，这样做有利于建立索引，提高查询效率。格式如下select sum（table1je） from table1 table1, table2 table2, table3 table3 where (table1的等值条件（=）) and (table1的非等值条件) and (table2与table1的关联条件) and (table2的等值条件) and (table2的非等值条件) and (table3与table2的关联条件) and (table3的等值条件) and (table3的非等值条件)。

注:关于多表查询时from 后面表的出现顺序对效率的影响还有待研究。

14 子查询问题。对于能用连接方式或者视图方式实现的功能，不要用子查询。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。应该用如下语句代替：select name from customer inner join order on customercustomer_id=ordercustomer_id where ordermoney>100。

15 在WHERE 子句中，避免对列的四则运算，特别是where 条件的左边，严禁使用运算与函数对列进行处理。比如有些地方 substring 可以用like代替。

16 如果在语句中有not in（in） *** 作，应考虑用not exists（exists）来重写,最好的办法是使用外连接实现。

17 对一个业务过程的处理，应该使事物的开始与结束之间的时间间隔越短越好，原则上做到数据库的读 *** 作在前面完成，数据库写 *** 作在后面完成，避免交叉。

18 请小心不要对过多的列使用列函数和order by,group by等，谨慎使用disti软件开发t。

19 用union all 代替 union，数据库执行union *** 作，首先先分别执行union两端的查询，将其放在临时表中，然后在对其进行排序，过滤重复的记录。

当已知的业务逻辑决定query A和query B中不会有重复记录时，应该用union all代替union，以提高查询效率。

数据更新的效率

1 在一个事物中，对同一个表的多个insert语句应该集中在一起执行。

2 在一个业务过程中，尽量的使insert,update,delete语句在业务结束前执行，以减少死锁的可能性。

数据库物理规划的效率

为了避免I/O的冲突，我们在设计数据库物理规划时应该遵循几条基本的原则(以ORACLE举例)：

table和index分离：table和index应该分别放在不同的tablespace中。

Rollback Segment的分离：Rollback Segment应该放在独立的Tablespace中。

System Tablespace的分离：System Tablespace中不允许放置任何用户的object。（mssql中primary filegroup中不允许放置任何用户的object）

Temp Tablesace的分离：建立单独的Temp Tablespace，并为每个user指定default Temp Tablespace

避免碎片：但segment中出现大量的碎片时，会导致读数据时需要访问的block数量的增加。对经常发生DML *** 作的segemeng来说，碎片是不能完全避免的。所以，我们应该将经常做DML *** 作的表和很少发生变化的表分离在不同的Tablespace中。

当我们遵循了以上原则后，仍然发现有I/O冲突存在，我们可以用数据分离的方法来解决。

连接Table的分离：在实际应用中经常做连接查询的Table，可以将其分离在不同的Taclespace中，以减少I/O冲突。

使用分区：对数据量很大的Table和Index使用分区，放在不同的Tablespace中。

在实际的物理存储中，建议使用RAID。日志文件应放在单独的磁盘中。

数据库的查询优化算法

给出你的查询，然后才可以对其进行优化

如何优化SQL Server数据库查询

如果你的查询比较固定，并且查询的条件区别度较高，可以建立相应的索引。

其他的一些规则，比如使用exists代替 in都可以试试

查询速度慢的原因很多，常见如下几种：

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 时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的 15 倍。如果另外安装了全文检索功能，并打算运行 Microsoft 搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。将 SQL Server max server memory 服务器配置选项配置为物理内存的 15 倍（虚拟内存大小设置的一半）。

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分离

10、分布式分区视图可用于实现数据库服务器联合体。联合体是一组分开管理的服务器，但它们相互协作分担系统的处理负荷。这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器，以支持大型的多层 Web 站点的处理需要。有关更多信息，参见设计联合数据库服务器。（参照SQL帮助文件'分区视图'）

a、在实现分区视图之前，必须先水平分区表

b、在创建成员表后，在每个成员服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。这样，引用分布式分区视图名的查询可以在任何一个成员服务器上运行。系统 *** 作如同每个成员服务器上都有一个原始表的复本一样，但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。

11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收缩数据和日志 DBCC SHRINKDB,DBCC SHRINKFILE 设置自动收缩日志对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。在T-sql的写法上有很大的讲究，下面列出常见的要点：首先，DBMS处理查询计划的过程是这样的：

1、 查询语句的词法、语法检查

2、 将语句提交给DBMS的查询优化器

3、 优化器做代数优化和存取路径的优化

4、 由预编译模块生成查询规划

5、 然后在合适的时间提交给系统处理执行

6、 最后将执行结果返回给用户其次，看一下SQL SERVER的数据存放的结构：一个页面的大小为8K(8060)字节，8个页面为一个盘区，按照B树存放。

12、Commit和rollback的区别 Rollback:回滚所有的事物。 Commit:提交当前的事物 没有必要在动态SQL里写事物，如果要写请写在外面如： begin tran exec(@s) mit 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 语句中的锁提示。锁提示 只读 乐观数值 乐观行版本控制 锁定无提示 未锁定 未锁定 未锁定 更新 NOLOCK 未锁定 未锁定未锁定 未锁定 HOLDLOCK 共享 共享 共享 更新 UPDLOCK 错误 更新 更新 更新 TABLOCKX 错误 未锁定 未锁定更新其它 未锁定 未锁定 未锁定 更新 指定 NOLOCK 提示将使指定了该提示的表在游标内是只读的。

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 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。这在SQL70以前是最重要的手段。例如医院的住院费计算。

26、MIN() 和 MAX()能使用到合适的索引。

27、数据库有一个原则是代码离数据越近越好，所以优先选择Default,依次为Rules,Triggers, Constraint（约束如外健主健CheckUNIQUE……,数据类型的最大长度等等都是约束）,Procedure这样不仅维护工作小，编写程序质量高，并且执行的速度快。

28、如果要插入大的二进制值到Image列，使用存储过程，千万不要用内嵌Insert来插入(不知JAVA是否)。因为这样应用程序首先将二进制值转换成字符串（尺寸是它的两倍），服务器受到字符后又将他转换成二进制值存储过程就没有这些动作: 方法：Create procedure p_insert as insert into table(Fimage) values (@image), 在前台调用这个存储过程传入二进制参数，这样处理速度明显改善

1、数据库空间是个概述，在sqlserver里，使用语句 exec sp_spaceused 'TableName'  这个语句来查。

2、sp_spaceused 该存储过程在系统数据库master下。exec sp_spaceused   '表名' --该表占用空间信息exec sp_spaceused    ' '      留空表示查询当前数据库占用空间信息。

3、接下来查看字段长度与已经使用的最大字段，使用如下命令。

4、最后查询整个数据库的空间大小，选中数据库，点击右键在下拉菜单中选择属性。

5、在常规里可以看到数据库可用空间，当发现可用空间太小的时候，就要扩大数据库空间了。

在JAVA开发中数据库的学习也是我们需要了解的，截下来几篇文章都是关于数据库的设计和应用，那么java课程培训机构废话不多说开始学习吧！

数据库的设计

数据库设计是基础，数据库优化是建立在设计基础之上的。好的数据库一定拥有好的设计。

数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效的运行环境。

数据库的三大范式

第一范式1NF:所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。

第二范式2Nf:第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

第三范式3Nf:所有字段必须与主键直接相关，而不是间接相关。也可以理解为字段不要和其他非主键字段相关

注意:这三个范式尽可能去遵守,不是一定要墨守成规这只是让我们设计的表的时候,越靠近这些范式,可以使字段尽量的减小冗余但是有时候也可以根据实际需要小小的违背一下但是第三范式违反一下还可以接受,但是第一范式别违反

数据库设计的步骤

需求分析阶段

准确了解与分析用户需求(包括数据与处理)。是整个设计过程的基础，是最困难、最耗费时间的一步。

概念结构设计阶段

是整个数据库设计的关键--设计数据库的E-R模型图，确认需求信息的正确和完整

Entity_Relationship---实体之间的关系

一对一

一对多

多对一

数据库优化可以从以下几个方面进行：

1结构层: web服务器采用负载均衡服务器,mysql服务器采用主从复制,读写分离

2储存层: 采用合适的存储引擎,采用三范式

3设计层: 采用分区分表,索引,表的字段采用合适的字段属性,适当的采用逆范式,开启mysql缓存

4sql语句层:结果一样的情况下,采用效率高,速度快节省资源的sql语句执行

数据千万级别之多，占用的存储空间也比较大，可想而知它不会存储在一块连续的物理空间上，而是链式存储在多个碎片的物理空间上。可能对于长字符串的比较，就用更多的时间查找与比较，这就导致用更多的时间。

可以做表拆分，减少单表字段数量，优化表结构。

在保证主键有效的情况下，检查主键索引的字段顺序，使得查询语句中条件的字段顺序和主键索引的字段顺序保持一致。

主要两种拆分 垂直拆分，水平拆分。

垂直分表

也就是“大表拆小表”，基于列字段进行的。一般是表中的字段较多，将不常用的， 数据较大，长度较长（比如text类型字段）的拆分到“扩展表“。 一般是针对 那种 几百列的大表，也避免查询时，数据量太大造成的“跨页”问题。

垂直分库针对的是一个系统中的不同业务进行拆分，比如用户User一个库，商品Product一个库，订单Order一个库。 切分后，要放在多个服务器上，而不是一个服务器上。为什么？ 我们想象一下，一个购物网站对外提供服务，会有用户，商品，订单等的CRUD。没拆分之前， 全部都是落到单一的库上的，这会让数据库的单库处理能力成为瓶颈。按垂直分库后，如果还是放在一个数据库服务器上， 随着用户量增大，这会让单个数据库的处理能力成为瓶颈，还有单个服务器的磁盘空间，内存，tps等非常吃紧。 所以我们要拆分到多个服务器上，这样上面的问题都解决了，以后也不会面对单机资源问题。

数据库业务层面的拆分，和服务的“治理”，“降级”机制类似，也能对不同业务的数据分别的进行管理，维护，监控，扩展等。 数据库往往最容易成为应用系统的瓶颈，而数据库本身属于“有状态”的，相对于Web和应用服务器来讲，是比较难实现“横向扩展”的。 数据库的连接资源比较宝贵且单机处理能力也有限，在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈。

水平分表

针对数据量巨大的单张表（比如订单表），按照某种规则（RANGE,HASH取模等），切分到多张表里面去。 但是这些表还是在同一个库中，所以库级别的数据库 *** 作还是有IO瓶颈。不建议采用。

水平分库分表

将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。

水平分库分表切分规则

1 RANGE

从0到10000一个表，10001到20000一个表；

2 HASH取模

一个商场系统，一般都是将用户，订单作为主表，然后将和它们相关的作为附表，这样不会造成跨库事务之类的问题。 取用户id，然后hash取模，分配到不同的数据库上。

3 地理区域

比如按照华东，华南，华北这样来区分业务，七牛云应该就是如此。

4 时间

按照时间切分，就是将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据 被查询的概率变小，所以没必要和“热数据”放在一起，这个也是“冷热数据分离”。

分库分表后面临的问题

事务支持

分库分表后，就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

跨库join

只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。

跨节点的count,order by,group by以及聚合函数问题

这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。

数据迁移，容量规划，扩容等问题

来自淘宝综合业务平台团队，它利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。

ID问题

一旦数据库被切分到多个物理结点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的ID无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得ID,以便进行SQL路由

一些常见的主键生成策略

UUID

使用UUID作主键是最简单的方案，但是缺点也是非常明显的。由于UUID非常的长，除占用大量存储空间外，最主要的问题是在索引上，在建立索引和基于索引进行查询时都存在性能问题。

Twitter的分布式自增ID算法Snowflake

在分布式系统中，需要生成全局UID的场合还是比较多的，twitter的snowflake解决了这种需求，实现也还是很简单的，除去配置信息，核心代码就是毫秒级时间41位 机器ID 10位 毫秒内序列12位。

跨分片的排序分页

一般来讲，分页时需要按照指定字段进行排序。当排序字段就是分片字段的时候，我们通过分片规则可以比较容易定位到指定的分片，而当排序字段非分片字段的时候，情况就会变得比较复杂了。为了最终结果的准确性，我们需要在不同的分片节点中将数据进行排序并返回，并将不同分片返回的结果集进行汇总和再次排序，最后再返回给用户。

以上就是关于SQL Server数据库的高性能优化经验总结全部的内容，包括:SQL Server数据库的高性能优化经验总结、SQL数据库优化的方法有哪些、mysql数据库如何优化，优化了哪些功能等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！