sql server数据库查询速度慢的原因有很多，常见的有：
1.没有索引或者没有使用索引(这是最常见的查询速度慢的问题，是编程的一个缺陷)
2.I/O吞吐量低，形成瓶颈效应。
3.该查询未优化，因为未创建计算列。
4.内存不足
5.网速慢
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？000，考虑将虚拟内存大小设置为计算机中安装的物理内存的1.5倍。如果还安装了全文搜索功能，并且您计划运行Microsoft search服务来执行全文索引和查询，请考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的3倍。将SQL Server最大服务器内存服务器配置选项配置为物理内存的1.5倍(虚拟内存大小设置的一半)。
7.增加服务器CPU的数量；但必须明白，并行处理和串行处理需要更多的内存等资源。使用并行还是串行笔划由MsSQL自动评估选择。如果一个任务被分解成多个任务，它可以在处理器上运行。比如延迟查询的排序、连接、扫描和按语句分组的同时执行，SQL SERVER根据系统的负载决定最优的并行级别，需要消耗大量CPU的复杂查询最适合并行处理。但是，更新操作update、INSERT和DELETE不能并行处理。
8.如果用like来查询，单纯用index不行，但是全文索引很消耗空间。像“%a %”一样使用索引，像“% a”一样不使用索引。用like“% a %”查询时，查询时间与字段值的总长度成正比，所以不能用CHAR类型，只能用VARCHAR。为长值字段建立全文索引。
9.数据库服务器和应用服务器的分离；OLTP和OLAP的分离
10.分布式分区视图可以用来实现数据库服务器联合体。
联合体是一组单独管理的服务器，但它们相互合作来分担系统的处理负荷。这种通过对数据进行分区来形成数据库服务器联盟的机制可以扩展一组服务器来支持大型多层网站的处理需求。有关详细信息，请参见设计联邦数据库服务器。(请参考SQL帮助文件“分区视图”)
a、在实现分区视图之前，必须对表进行水平分区。
b、创建成员表后，在每个成员服务器上定义一个分布式分区视图，每个视图同名。这样，引用分布式分区视图名称的查询可以在任何成员服务器上运行。系统的运行就好像每个成员服务器都有一个原始表的副本，但实际上每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。
1.重建索引DBCC REINDEX，DBCC INDEXDEFRAG，收缩数据和日志DBCC SHRINKDB，DBCC SHRINKFILE。设置自动收缩日志。对于大型数据库，不要设置数据库自动增长，这会降低服务器的性能。
非常强调T-sql的编写。以下是共同点：一、DBMS处理查询计划的流程如下：
1.检查查询语句的词法和语法。
2.将语句提交给DBMS的查询优化器。
3.优化器执行代数优化和访问路径优化。
4.预编译模块生成查询计划。
5.然后将其提交给系统，以便在适当的时间进行处理和执行。
6.最后，将执行结果返回给用户。
其次看SQL SERVER的数据存储结构：一页的大小是8K(8060)字节，八页是一个盘区，按照B树存储。
12.提交和回滚的区别。回滚：回滚所有内容。提交：提交当前的事情。不需要用动态SQL写东西。如果要写的话，请写在外面，比如：begin tran exec(@s) commit trans或者把动态SQL写成函数或者存储过程。
13.在查询Select语句中，使用Where语句限制返回的行数，以避免表扫描。如果返回不必要的数据，会浪费服务器的I/O资源，增加网络负担，降低性能。如果表非常大，那么在表扫描过程中会被锁定，其他连接将被禁止访问表，这将产生严重的后果。
14.SQL的注释语句对执行没有影响。
15.尽量不要用光标，它占用了很多资源。如果需要逐行执行；尝试采用非光标技术；如：在客户端骑行；使用临时表；表变量；子查询；案例陈述；等等。
游标可以根据其支持的提取选项进行分类：只进行必须从第一行提取到最后一行。FetcH NEXT是唯一允许的FetcH操作，也是默认方式。可滚动性可以在游标中任意位置随机选择任意行。游标技术在SQL2000下变得非常强大，其目的是支持循环。
有四个并发选项，READ_ONLY:不允许通过游标进行更新，组成结果集的行中没有锁。
优化值：乐观并发控制是事务控制理论的标准部分。并发控制用于第二个用户在打开游标和更新行之间的时间间隔内很少有机会更新行的情况。当使用此选项打开游标时，没有锁来控制它的行，这将有助于最大化它的处理能力。如果用户试图修改某一行，该行的当前值将与上次提取该行时获得的值进行比较。如果任何值发生变化，服务器将知道其他人已经更新了该行，并将返回一个错误。如果值相同，服务器将执行修改。
选择此行版本控制最佳并发选项：此开放式并发控制选项基于行版本控制。对于行版本控制，表必须有某个版本标识符，服务器可以使用该标识符来确定行在读取游标后是否发生了更改。在SQL Server中，这种性能是由timestamp数据类型提供的，它是一个二进制数，表示数据库中更改的相对顺序。
每个数据库都有一个全局的当前时间戳值：@@DBTS。每当带有时间戳列的行以任何方式更改时，SQL Server首先将当前的@@DBTS值存储在时间戳列中，然后增加@@DBTS的值。如果一个表有一个时间戳列，时间戳将被记录在行级别。服务器可以将行的当前时间戳值与上次提取时存储的时间戳值进行比较，以确定该行是否已被更新。服务器不必比较所有列的值，只需比较时间戳列。如果应用程序需要基于无时间戳列的表的行版本控制的开放式并发，则游标默认为基于数值的开放式并发控制。滚动锁该选项实现悲观并发控制。在悲观并发控制中，当数据库行被读入游标结果集时，应用程序将尝试锁定数据库行。使用服务器游标时，在将更新锁读入游标时，会将该锁放在一行上。如果在事务中打开了游标，事务更新锁将一直保持到事务被提交或回滚；选择下一行时，光标锁定将被移除。如果游标是在事务之外打开的，则在提取下一行时，锁将被丢弃。
因此，每当用户需要完全悲观的并发控制时，应该在事务内打开游标。更新锁将阻止任何其他任务获取更新锁或排他锁，从而阻止其他任务更新该行。但是，更新锁不会阻止共享锁，因此它不会阻止其他任务读取行，除非第二个任务也请求使用更新锁进行读取。滚动锁这些游标并发选项可以根据游标定义的SELECT语句中指定的锁提示生成滚动锁。在提取时，将在每一行上获取滚动锁，并一直保持到下一次提取或游标关闭，以先发生的为准。在下一次提取时，服务器获取新提取的行的滚动锁，并释放最后提取的行的滚动锁。滚动锁独立于事务锁，可以保持到提交或回滚操作之后。如果commit时关闭游标的选项为off，则commit语句不会关闭任何打开的游标，并且在COMMIT之后会保留滚动锁，以保持提取数据的隔离。获得的滚动锁的类型取决于游标并发选项和游标SELECT语句中的锁提示。提示只读乐观值。
指定NOLOCK提示将使用该提示指定的表在游标中变为只读。
16.使用Profiler跟踪查询，得到查询所需的时间，找出SQL的问题；使用索引优化器优化索引
17.注意UNion和UNion all的区别。工会一切都好
18.注意使用DISTINCT，不必要的时候不要用。它会像UNION一样降低查询速度。重复记录在查询中没有问题。
19.查询时不要返回不必要的行和列。
20.请使用sp _ configure ' ' QUERY GOVERNOR COST LIMIT ' '或SET QUERY_GOVERNOR_COST_LIMIT来限制查询所消耗的资源。当评估查询消耗的资源超过限制时，服务器自动取消查询，并在查询前将其杀死。设置锁定时间设置锁定时间。
21.使用select top 100/10 Percent限制用户返回的行数，或设置ROWCOUNT限制操作的行数。
22.在SQL2000之前，一般不使用以下词语：' IS NULL ''''=' '' '''非''不存在''不在''不像'和'像' ' P
