怎样才能加速sqlserver的查询速度

[tianyamoon]

除了建立索引之外，怎样才能加速sqlserver的查询速度（好几百万条记录），前些天听别人说sqlserver内部有加速查询的功能，但是语焉不详，只好到这里求救了

[子陌红尘]

对表分区，优化查询语句，升级硬件，and so on ...

[phantomMan]

如果实在要提高性能,而条件允许的话,可以进行反范式化操作

[iamltd]

优化查询速度不是一两句话说得完的
不管是索引、表分区、SQL语句都有很大影响。当然，提升硬件也是个好办法

[zonelive]

把这个表放到缓存中，直接在缓存中读出当然是最快啦，但是有一个很大的缺点，除非你的这个表是很常用的，要不它一直占住你的缓存空间，我想后果你应该明白

[MorningTea]

索引，设计表的结构的时候，key值栏位最好是数字或者字母，远比中文来得快，最好是单一栏位，
为了不同的用途，也可以动态建立索引，看情况而言啦！
如果大概30个字符左右，那么尽量用char(50),不要用varchar(50)（当然用varchar(50)比较方便）
为了加快查询速度，可以考虑fulltext,全文检索，对于长字串的栏位，我们不会建立所以，那么用全文检索可以解决我们的难题
...
好多~

[duanduan1122]

使用有效的查询设计


某些类型的查询天生就要占用大量的资源。这与大多数关系型数据库管理系统 (RDBMS) 常见的数据库和索引重大问题有关，而不是 SQL Server 特有的。它们并非是低效的，因为优化程序将以尽可能最为有效的方式来实现这些查询。但它们仍会占用大量的资源，而 SQL 面向集合的特性使它们显得效率很低。优化程序对于消除这些结构天生对资源的大量消耗毫无办法。与较简单的查询相比，它们非常耗费资源。尽管 SQL Server 将使用最为优化的访问计划，还是受可能占用大量资源的基线的限制。

例如：
• 大型结果集
• IN、NOT IN 及 OR 查询
• 高度非唯一 WHERE 子句
• !=（不等于）比较运算符
• 某些列函数，如 SUM
• WHERE 子句中的表达式或数据转换
• WHERE 子句中的局部变量
• GROUP BY 的复杂视图
许多因素使得有必要使用这些查询结构。如果优化程序能在执行占用大量资源的部分查询之前限制结果集的大小，这些查询结构对性能的影响将被减少。下边给出了几个例子。

[duanduan1122]

占用大量资源的查询：
SELECT SUM(SALARY) FROM TABLE

占用较少资源的查询：
SELECT SUM(SALARY) FROM TABLE WHERE
ZIP='98052'

占用大量资源的查询：
SELECT * FROM TABLE WHERE
LNAME=@VAR

[duanduan1122]

占用较少资源的查询：
SELECT * FROM TABLE
WHERE LNAME=@VAR AND ZIP='98052'

在第一个例子中，SUM 操作无法通过索引加快。因为每一行都得读取并累加。假定在 ZIP 列上有一个索引，优化程序将很可能在应用 SUM 之前先用它来限制结果集。这样速度会快得多。

在第二个例子中，只有在运行时才会解析局部变量。但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，@VAR 值还是未知的，因而无法作为索引选择的输入项。

以上示例中用于改善性能的技术，涉及到用 AND 子句来限制结果集。作为另一种替代技术，可以使用一个存储过程，并把给 @VAR 的值作为参数传递给存储过程。

有些情况下，最佳做法是使用一组简单的查询，并通过临时表存储中间结果，这比使用单个复杂查询好得多。

对于大多数 RDBMS，大型结果集是很耗费资源的。您应该尽量避免把一个大型的结果集作为最终的数据选择返回给客户。限制结果集的大小，而让数据库系统完成本来属于它的一些功能，效率会更高。这将减少网络 I/O，并使得应用程序适合于通过慢速远程通讯链接的部署。随着应用程序扩展到更多的用户，它还会改善与并发相关的性能。

[hglhyy]

要真正的优化，得从建表的时候开始，表结构是不是合理，索引、主键、外键
还有依附的 触发器 等等，都得考虑，这是单从表，大到从一个库中的所有的表的合理性，使用频率高的表得想办法达到最优化的状态！

其次，你的硬件的配制要跟上！

[zonelive]

DBCC PINTABLE
将表标记为驻留，这表示 Microsoft® SQL Server™ 不从内存中刷新表页。

语法
DBCC PINTABLE ( database_id , table_id )

参数
database_id

是要驻留的表的数据库标识 (ID) 号。若要确定该数据库 ID，请使用 DB_ID 函数。

table_id

是要驻留的表的对象标识号。若要确定表 ID，请使用 OBJECT_ID 函数。

注释
DBCC PINTABLE 不会导致将表读入到内存中。当表中的页由普通的 Transact-SQL 语句读入到高速缓存中时，这些页将标记为内存驻留页。当 SQL Server 需要空间以读入新页时，不会清空内存驻留页。SQL Server 仍然记录对页的更新，并且如有必要，将更新的页写回到磁盘。然而，在使用 DBCC UNPINTABLE 语句使该表不驻留之前，SQL Server 在高速缓存中一直保存可用页的复本。

DBCC PINTABLE 最适用于将小的、经常引用的表保存在内存中。将小表的页一次性读入到内存中，将来对其数据的所有引用都不需要从磁盘读入。



注意 DBCC PINTABLE 可以提供性能改进，但是使用时务必小心。如果驻留大表，则该表在开始时会使用一大部分高速缓存，而不为系统中的其它表保留足够的高速缓存。如果所驻留的表比高速缓存大，则该表会填满整个高速缓存。sysadmin 固定服务器角色的某个成员必须关闭而后重新启动 SQL Server，然后使表不驻留。驻留太多的表和驻留比高速缓存大的表会产生同样的问题。

[postfxj]

提高sql server的性能是一個復雜的問題，得具體問題具體分析了。
一定得要有索引查詢效率才會上去。如果有復雜的運算統計服務器本身的性能很重要。