首先感谢各位的帮忙有人要看SQL语句，其实说实话，这些表设计不合理，但这些是上级机构给的，不能变的现在执行SELECT * FROM TABLENAME都需要30~50秒，这个表有96个列，有三种类型，GUID，DATETIME，VARCHAR索引也反复测试了，没有明显效果，目前为了不耽误用户使用，已经开始改成分表存储。目前只能这样了！再次感谢各位帮助！
700万 只能说是很普通的表 我们测试数据都是至少几千万条的记录的单表.重要的是 你返回的 最好不必全部返回吧 只返回你所需要的一小部分 一般是没有任何问题的700 万条 你去 select * from tablename 而没有where 条件过滤 这肯定是疯了 你可以去 Select top 1000 你需要的字段 from TableName where 如果是需要统计更简单了 结果一般只会有几行到几百 或者 上千行 应当都不算多的了, 速度也会很快啊 不知道你们这种表结构和程序是如何设计的.
我目前也为此问题发愁，呵呵，只是想知道各位是如何知道查询速度的快慢的，第一次查询30秒没结果，第二次不到一秒，呵呵这个问题我早就提出了。 测试查询的速度时，有必要多次运行此查询，然后取一个平均值。因为查询(或存储过程)可能会存储在 SQL Server 内存中的过程缓存中，因此第一次尝试耗费的时间好像稍长一些，而所有后续尝试耗费的时间都较短。另外，运行您的查询时，可能正在针对相同的表运行其他查询。当其他查询锁定和解锁这些表时，可能会导致您的查询要排队等待。例如，如果您进行查询时某人正在更新 此表中的数据，则在更新提交时您的查询可能需要耗费更长时间来执行
存储过程编写经验和优化措施 阅读提示：本文介绍MS SQL的存储过程编写经验和优化措施 一、适合读者对象：数据库开发程序员，数据库的数据量很多，涉及到对SP（存储过程）的优化的项目开发人员，对数据库有浓厚兴趣的人。 二、介绍：在数据库的开发过程中，经常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作。如果项目的SP较多，书写又没有一定的规范，将会影响以后的系统维护困难和大SP逻辑的难以理解，另外如果数据库的数据量大或者项目对SP的性能要求很，就会遇到优化的问题，否则速度有可能很慢，经过亲身经验，一个经过优化过的SP要比一个性能差的SP的效率甚至高几百倍。 三、内容： 1、开发人员如果用到其他库的Table或View，务必在当前库中建立View来实现跨库操作，最好不要直接使用“databse.dbo.table_name”，因为sp_depends不能显示出该SP所使用的跨库table或view，不方便校验。 2、开发人员在提交SP前，必须已经使用set showplan on分析过查询计划，做过自身的查询优化检查。 3、高程序运行效率，优化应用程序，在SP编写过程中应该注意以下几点： a)SQL的使用规范： i. 尽量避免大事务操作，慎用holdlock子句，提高系统并发能力。 ii. 尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考虑先根据条件提取数据到临时表中，然后再做连接。 iii. 尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过万行，那么就应该改写；如果使用了游标，就要尽量避免在游标循环中再进行表连接的操作。 iv. 注意where字句写法，必须考虑语句顺序，应该根据索引顺序、范围大小来确定条件子句的前后顺序，尽可能的让字段顺序与索引顺序相一致，范围从大到小。 v. 不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。 vi. 尽量使用exists代替select count(1)来判断是否存在记录，count函数只有在统计表中所有行数时使用，而且count(1)比count(*)更有效率。 vii. 尽量使用“>=”，不要使用“>”。 viii. 注意一些or子句和union子句之间的替换 ix. 注意表之间连接的数据类型，避免不同类型数据之间的连接。 x. 注意存储过程中参数和数据类型的关系。 xi. 注意insert、update操作的数据量，防止与其他应用冲突。如果数据量超过个数据页面（k），那么系统将会进行锁升级，页级锁会升级成表级锁。 b)索引的使用规范： i. 索引的创建要与应用结合考虑，建议大的OLTP表不要超过个索引。 ii. 尽可能的使用索引字段作为查询条件，尤其是聚簇索引，必要时可以通过index index_name来强制指定索引 iii. 避免对大表查询时进行table scan，必要时考虑新建索引。 iv. 在使用索引字段作为条件时，如果该索引是联合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用。 v. 要注意索引的维护，周期性重建索引，重新编译存储过程。 c)tempdb的使用规范： i. 尽量避免使用distinct、order by、group by、having、join、cumpute，因为这些语句会加重tempdb的负担。 ii. 避免频繁创建和删除临时表，减少系统表资源的消耗。 iii. 在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免log，提高速度；如果数据量不大，为了缓和系统表的资源，建议先create table，然后insert。 iv. 如果临时表的数据量较大，需要建立索引，那么应该将创建临时表和建立索引的过程放在单独一个子存储过程中，这样才能保证系统能够很好的使用到该临时表的索引。 v. 如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后drop table，这样可以避免系统表的较长时间锁定。 vi. 慎用大的临时表与其他大表的连接查询和修改，减低系统表负担，因为这种操作会在一条语句中多次使用tempdb的系统表。 d)合理的算法使用： 根据上面已提到的SQL优化技术和ASE Tuning手册中的SQL优化内容,结合实际应用,采用多种算法进行比较,以获得消耗资源最少、效率最高的方法。具体可用ASE调优命令：set statistics io on, set statistics time on , set showplan on 等。
如果是sql2000考虑分表.汇总报表可以是截止到某个时间的报表,晚上用job转出结果来单独存.
1.优化你的查询语句。
2.更改数据表里面的数据项。如在非必须情况下date->smalldate。
3.表里面是否有有冗余项。
700W数据都不算大的，，，，
只要优化你的SQL，跟多加些索引就行了，，
700W数据完全可以达到要求的
这个就不用说了，我SQL也玩了3~4年了这个库是上级单位给的，变不了的，结构不算合理，但不能改我查询的语句，应该没法再精简了，我也和同事推敲过。现在就是想在这样的情况下，还有什么方法提高，索引也建了，不明显。
2.用存储过程可以提高性能
3.优化SQL语句，要从逻辑上去考虑完善
4.良好的算法，时间和空间复杂度尽可能小
不过lz的表看来尽是字符串 建议先哈希到整数上 建索引后会很快的
700W数量确实不多
如果表里面的市、区等信息都存放的是中文的话，建议另外建表存放这些信息，比如create table city --建立市表
(
cid int,
cname varchar(20)
)然后把大表里面的市全换成cid存储，这样建立索引也节省空间，速度也会快很多。
所以建议lz还是把表结构贴出来。
另外使用NUMA节点技术是2005才支持的
同感，依据你的查询来增加索引，试试在索引里加入include列。
更多的纪录我都可以很快，这个应该跟查询应用有关。
建议LZ把主要的查询SQL贴出来,大家一起来分析一下好了.
1.优化你的查询语句。
2.更改数据表里面的数据项。如在非必须情况下date->smalldate。
3.表里面是否有有冗余项。
楼主是什么操作比较慢呀？如果是查询的话，索引应该建立在查询条件那些列上。
另外，不知道SQL Server有没有类似于buffer pool的概念，可以试一试调大一下buffer pool。
其实，楼主最重要的是找到瓶颈，你看一看瓶颈到底是不是在数据库上，如果单独在企业管理器里面执行
那条SQL语句，是不是也会特别慢？如果不慢的话，有可能是网络或者客户机或者应用上的问题。如果瓶颈
在查询优化上，楼主倒是可以试一试存储过程。一般来说，数据库的瓶颈会是IO，但是700W条数据，即使是
IO问题，也不至于感觉到慢。
如果方便的话，楼主不如试一试DB2或者ORACLE，看看是不是同样慢。
那就考虑以空间换时间：预先计算存储中间统计结果，实际查询时以它为依据
你可以去 Select top 1000 你需要的字段 from TableName where 如果是需要统计更简单了 结果一般只会有几行到几百 或者 上千行 应当都不算多的了,
速度也会很快啊 不知道你们这种表结构和程序是如何设计的.
你几千W？我几亿也一个表。
关键不是看记录数的多少，而是要看数据占用了多数据页。
以及你并发数量及io处理情况.
测试查询的速度时，有必要多次运行此查询，然后取一个平均值。因为查询(或存储过程)可能会存储在 SQL Server 内存中的过程缓存中，因此第一次尝试耗费的时间好像稍长一些，而所有后续尝试耗费的时间都较短。另外，运行您的查询时，可能正在针对相同的表运行其他查询。当其他查询锁定和解锁这些表时，可能会导致您的查询要排队等待。例如，如果您进行查询时某人正在更新 此表中的数据，则在更新提交时您的查询可能需要耗费更长时间来执行
阅读提示：本文介绍MS SQL的存储过程编写经验和优化措施
一、适合读者对象：数据库开发程序员，数据库的数据量很多，涉及到对SP（存储过程）的优化的项目开发人员，对数据库有浓厚兴趣的人。
二、介绍：在数据库的开发过程中，经常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作。如果项目的SP较多，书写又没有一定的规范，将会影响以后的系统维护困难和大SP逻辑的难以理解，另外如果数据库的数据量大或者项目对SP的性能要求很，就会遇到优化的问题，否则速度有可能很慢，经过亲身经验，一个经过优化过的SP要比一个性能差的SP的效率甚至高几百倍。
三、内容：
1、开发人员如果用到其他库的Table或View，务必在当前库中建立View来实现跨库操作，最好不要直接使用“databse.dbo.table_name”，因为sp_depends不能显示出该SP所使用的跨库table或view，不方便校验。
2、开发人员在提交SP前，必须已经使用set showplan on分析过查询计划，做过自身的查询优化检查。
3、高程序运行效率，优化应用程序，在SP编写过程中应该注意以下几点：
a)SQL的使用规范：
i. 尽量避免大事务操作，慎用holdlock子句，提高系统并发能力。
ii. 尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考虑先根据条件提取数据到临时表中，然后再做连接。
iii. 尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过万行，那么就应该改写；如果使用了游标，就要尽量避免在游标循环中再进行表连接的操作。
iv. 注意where字句写法，必须考虑语句顺序，应该根据索引顺序、范围大小来确定条件子句的前后顺序，尽可能的让字段顺序与索引顺序相一致，范围从大到小。
v. 不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
vi. 尽量使用exists代替select count(1)来判断是否存在记录，count函数只有在统计表中所有行数时使用，而且count(1)比count(*)更有效率。
vii. 尽量使用“>=”，不要使用“>”。
viii. 注意一些or子句和union子句之间的替换
ix. 注意表之间连接的数据类型，避免不同类型数据之间的连接。
x. 注意存储过程中参数和数据类型的关系。
xi. 注意insert、update操作的数据量，防止与其他应用冲突。如果数据量超过个数据页面（k），那么系统将会进行锁升级，页级锁会升级成表级锁。
b)索引的使用规范：
i. 索引的创建要与应用结合考虑，建议大的OLTP表不要超过个索引。
ii. 尽可能的使用索引字段作为查询条件，尤其是聚簇索引，必要时可以通过index index_name来强制指定索引
iii. 避免对大表查询时进行table scan，必要时考虑新建索引。
iv. 在使用索引字段作为条件时，如果该索引是联合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用。
v. 要注意索引的维护，周期性重建索引，重新编译存储过程。
c)tempdb的使用规范：
i. 尽量避免使用distinct、order by、group by、having、join、cumpute，因为这些语句会加重tempdb的负担。
ii. 避免频繁创建和删除临时表，减少系统表资源的消耗。
iii. 在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免log，提高速度；如果数据量不大，为了缓和系统表的资源，建议先create table，然后insert。
iv. 如果临时表的数据量较大，需要建立索引，那么应该将创建临时表和建立索引的过程放在单独一个子存储过程中，这样才能保证系统能够很好的使用到该临时表的索引。
v. 如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后drop table，这样可以避免系统表的较长时间锁定。
vi. 慎用大的临时表与其他大表的连接查询和修改，减低系统表负担，因为这种操作会在一条语句中多次使用tempdb的系统表。
d)合理的算法使用：
根据上面已提到的SQL优化技术和ASE Tuning手册中的SQL优化内容,结合实际应用,采用多种算法进行比较,以获得消耗资源最少、效率最高的方法。具体可用ASE调优命令：set statistics io on, set statistics time on , set showplan on 等。
[email protected],你把要怎么做发给我，我可以帮你看看．