怎样改进数据库的查询性能

1、使你的数据库结构规范化，但是不要求一定达到第三范式，为了显示和打印目的可以有数据冗余2、评估你的系统中对性能影响的关键处，减少被频繁访问的核心表的数量，并在这些核心

表上重点优化索引，表结构（尽量紧凑）。典型的核心表是代码表。

3、对于统计类应用，如果可能应写成触发器和存储过程，这样就有可能把一个消耗大量时

间的统计运算分布到每INSERT，DELETE，或者UPDATE来处理，从而极大提高查询类 *** 作的速度。

查询选择群居索引最有效。其他索引也要针对业务进行选择。由于维护索引也要消耗系

统资源和时间，所以过多的索引对性能是损害甚至是毫无效果的。

5、如果可能，可以利用大数据库对SQL的一些特殊规定来进一步优化，比如查询暗示。

6、适当选择硬件，综合考虑CPU，内存，I/O系统的性能，以当前的CPU，内存配置来看，

很多数据库系统的瓶颈出在I/O系统上。所以如果有可能，最好使用RAID。

当然如果你有足够的财力，可以买更好的服务器，或者搞服务器集群就更利害啦。

7、可能的话，尽量使用存储过程，因为存储过程的执行计划可以重复使用，而且不需要

象普通由CLIENT提交的SQL那样进行处理和编译。

8、检查你的应用程序设计，如果有可能，尽量减少查询次数和在网络上往返的数据。为了

获取少量字段而写SELECT 对性能的损害也比较利害。

9、在应用程序中协调并发和一致性之间的矛盾。并不是所有业务都需要放在事务中。大量

业务是允许脏读的，在不关键事务中使用脏读，或者读提交，可以大大降低DEADLOCK和

进程之间彼此等待的机会，从而把由于互相锁定资源引起的等待降低到最小。

不要在事务执行中进行大量计算或者与用户交互的 *** 作，因为事务的执行在要求上是

不允许被打断的原子 *** 作（回滚是失败的），所以事务应该多而短小。长事务会锁住

很多资源比较长的时间，因此也比较容易导致其他进程对资源的等待和死锁的机会。

10、评估你开发系统的关键业务，在很多数据库系统对性能的要求是彼此矛盾的，比如OLTP

应用和DSS是不同的。DSS倾向于使用各种索引加快检索速度，而大量的索引对OLTP则是负担。

11、不要在应用程序中写怪异的SQL 查询，比如 WHERE money!40000，这样的语句，这种

SQL查询，数据库的SQL优化器是无法进行优化的。

12、定期维护和管理你的数据库系统，压缩掉那些垃圾空间，很多数据库系统执行类似

删除，事务等 *** 作的时候，并不回收无用的物理空间。所以，制定一份合理的数据库

维护计划，不要等日志文件或者LOG文件越长越大的时候才去整理数据库。

还有很多很多要注意的东西，。。。。。。

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 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树存放。

哥们的描述很模糊哦，

在线访问，说明应该有可视化界面，可以使用loadrunner工具去录制界面 *** 作然后跑并发即可，设置Vuser数，Vuser数一定条件下可以理解为你的在线用户数。将这个值一直往上加，压到你的服务器CPU,MEN,IO等还剩下20%左右的时候得出最大活跃用户数，然后再反推在线用户数。

PS：

用户在线对服务器的压力不大，登陆后未必会 *** 作， *** 作的话也未必会同时 *** 作，压力点在于活跃用户数，比如1000个在线，有100个用户处于活跃状态，其他900个非活跃状态。那么就是1:9

至于我说得方法合不合适，还得根据你服务器的实际情况而论。

以上就是关于怎样改进数据库的查询性能全部的内容，包括:怎样改进数据库的查询性能、SQL数据库性能怎么样、如何测试数据库服务器的负载性能等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！