Ⅰ 如何优化sqlserver order by
1、整理 或者 重建一下索引
2、order by fbsj desc 里面的 fbsj 是否可以改成 order by id desc，如果数据逻辑可以的话，建立一个ID 聚集索引 ，在 order by 的时候，聚集索引比 非聚集索引快很多
Ⅱ 数据库的查询优化方法分析
尽量不要使用 or 使用or会引起全表扫描 将大大降低查询效率
alice like % &abigale& % 会使索引不起作用(针对sqlserver)
经过实践验证 charindex()并不比前面加%的like更能提高查询效率 并且charindex()会使索引失去作用（指sqlserver数据库）
字段提取要按照 需多少 提多少 的原则 避免 select * 尽量使用 select 字段 字段 字段 实践证明 每少提取一个字段 数据的提取速度就会有相应的提升 提升的速度还要看您舍弃的字段的大小来判断
order by按聚集索引列排序效率最高 一个sqlserver数据表只能建立一个聚集索引 一般默认为ID 也可以改为其它的字段
能使用exists和not exists尽量使用 避免使用in或not in
能使用表连接尽量使用 避免使用exists和not exists
SET NOCOUNT ON
正确使用UNION和UNION ALL
慎用SELECT DISTINCT
少用游标
使用表的别名(Alias)
当在SQL语句中连接多个表时 请使用表的别名并把别名前缀于每个Column上 这样可以减少解析的时间并减少那些由Column歧义引起的语法错误
尽量少使用游标
原因很简单;就是游标的算法是最原始的计算机算法(和for if等语句一样 一条条搜索来算;效率极低);
而sql语句用的是集合运算;速度则快的多;如果用索引速度则很快(用了指针)
创建索引
a 聚集索引:
聚集索引是磁盘存储和逻辑显示是一样的
mssql表的主键一般是聚集索引;主键(每一条记录唯一确定);
创建的主键自动会是聚集索引;
如有一个非常大的表(有百万行);很长时间磁盘存储上会有类似碎片(磁盘填充率效率低;一般是频繁删除造成的);
要提高它的性能的最简洁办法是:把这个表的主键去掉再保存后;然后重新设主键再保存;
(这个表就会在磁盘上重新整理排序;性能当然会提高哟)
b 非聚集索引:
非聚集索引是在外面建立小的附加表(一种树形结构;大多数是B或B+树);
读(遍历select等sql语句)表特快;但写(update;delete insert等sql语句)表性能会略微下降
针对数据量大的表建议非聚集索引不要超过 个(节省额外磁盘负担)
不要给类似 性别 列创建索引
死锁:
是指有线程在读一条记录;别的线程读这条记录就要等待;
在mssql中只要长期占那条记录的线程去掉;死锁就会解除
在mssql中锁是针对每一行记录(所以性能不错)
经常产生锁的原因有:
a 在sql语句中使用事务语句(特别是事务中当查询比较耗时)
b 在前台的应用程序的connetion冲突(未关闭)
c 多表联合查询(尤其是在打开大的数据集时)
sql语句优化
a is null not or in 不会用索引
b 避免在索引列上使用计算或函数处理(索引会大失性能) 还有 % ;有的甚至会全失索引性能
c SELECT中避免使用 * (宁可把需要字段列出来;而不要用*去把所有的字段都列出来)
d 避免相关子查询(select中套select)
e where的条件中 =＞exists＞in (指性能)
f order by group by having distinct 等语句要慎用(因为它们效率不高;它们是先把数据到临时表中再进行处理的)
g 聚集索引如有 个字段组成(tt 和tt );tt 在前面;where的条件中如只用tt 字段来判断;就会用到一半的聚集索引;
where的条件中如tt 和tt 字段都用来判断了;就会全用到聚集索引;
where的条件中如只用tt 字段来判断;就会用不到聚集索引了;
尽量不要使用TEXT数据类型
除非你使用TEXT处理一个很大的数据 否则不要使用它 因为它不易于查询 速度慢 用的不好还会浪费大量的空间
一般的 VARCHAR可以更好的处理你的数据
尽量不要使用临时表
尽量不要使用临时表 除非你必须这样做 一般使用子查询可以代替临时表 使用临时表会带来系统开销
如果前台的代码你是使用数据库连接池而临时表却自始至终都存在 SQL Server提供了一些替代方案 比如Table数据类型
尽量少使用外键和触发器
因为在mssql中这些功能的性能做得不是很好;随便动一下表(它就会到相关的表去搞判断;有很多情况并不需要);在后台消耗资源大
lishixin/Article/program/Oracle/201311/16744
Ⅲ 关于SQLServer 2000 索引问题
没法解决！
每日写入10万左右，1d=24H=24*60m=24*60*60s=86400s 这才8万多条记录，每秒钟至少写入一条记录，这个已经不是关系库可以承受的了。
你该跟领导说明情况，让他知道还有个“实时数据库”，这个才是解决办法。
如PI、eDNA等实时库才是能承受。
别说sql2000性能不好，就算用oracle11r2也不成。
如果非得用关系库，那就考虑分表吧。
例如：主键一般都是有含义的，如 年份+序号，字母+序号..按照某一规律进行分表，然后将各分表连接做成一个视图。
Ⅳ SQL数据库容量大，查询速度慢，有何解决方案
首先应该确定是谁慢的，往往是程序处理方面的问题而不是数据库的问题。
程序方面应该尽可能的减少数据查询返回的内容，比如可以查询返回ID，然后再根据ID一条一条的查询具体内容，看似慢了，在数据量达的时候快很多
对于数据可以参照下面几点
1、优化SQL语句，SQL语句对查询速度影响最大
2、对于经常查询的字段作索引。但是这样会增加修改时的压力
4、优化SQLServer，比如给其分配固定的内存，预先分配查询内存，调整CPU使用率等。
5、优化硬件资源，比如使用更高的服务器或者硬盘，独立安排数据库的数据文件和索引文件，将数据文件分布于不同的物理硬盘上等等
6、考虑使用分布数据库或者对大表进行拆分
另外，2G的数据库应该不算很大了，我处理过18G的数据库，8000万条记录，查询速度可以被接受
Ⅳ 浅谈如何优化SQL Server服务器
数据和日志文件分开存放在不同磁盘上
数据文件和日志文件的操作会产生大量的I/O 在可能的条件下 日志文件应该存放在一个与数据和索引所在的数据文件不同的硬盘上以分散I/O 同时还有利于数据库的灾难恢复
tempdb数据库单独存放在不同磁盘上
tempdb数据库是其他所有数据库都有可能使用的临时数据库 当使用select into 在没建立索引的列上执行Orderby时就会在tempdb数据库中产生临时表来存储中间数据 由于建立和填充临时表会严重降低系统性能 所以在尽可能的情况下应该为要排序的列建立索引 同时 tempdb数据库是为所有的用户和应用程序共享 所以如果一个用户占据了tempdb数据库的所有空间 则其他数据库将不能再使用 在可能的情况下 tempdb数据库应该单独放置在一个速度更快的硬盘或者RAID阵列上 分离tempdb数据库的I/O操作以加快性能 tempdb数据库应该有适当的容量 以满足用户的需要 应该允许tempdb数据库的空间自动增长 如果设置为不允许自动增长 当查询操作建立了超过tempdb数据库容量的临时表时 操作将无法完成
适当设置tempdb数据库的增长幅度 过小的增长幅度会产生更多的外部碎片 会占用更多的资源
避免热点数据的发生
在SQLServer 之前 对于没有聚集索引的表（堆集表） 新插入的数据行总是放置在磁盘中表的物理结尾处 如果并发的用户很多 同时在对表执行插入或者更新数据的操作 这将使得十分繁忙的表的末尾有可能产生数据热点 并发的I/O操作集中对少数页面进行操作 将导致数据库性能的下降
在SQLServer中 新的数据行的物理存储空间的分配是通过PFS页面来进行的 PFS页面的管理算法将插入操作进行分散来尽量避免产生数据热点
在设计应用系统和数据库时 要避免在自然增长的列上建立主键 这样有可能导致热点数据的发生
数据类型要少
在设计表时 尽可能少用数据类型 这样一个数据页面上可以保存最多的信息 数据页面就少 检索数据页面的I/O操作就少 所以效率会高
监控和整理空间碎片
文件空间的自动增长提高了自动管理性 但可能导致空间碎片 物理空间与数据的逻辑空间不再连续 定期的监控和空间碎片整理有利于提高I/O性能
使用主数据文件和次要数据文件
每个数据库的一个主数据文件属于主文件组 对于 GB左右规模的数据库 一个数据文件就够了 如果有次要数据文件 主数据文件中有管理次要数据文件的指针
采用多个数据文件时 主数据文件用于存储系统对象和表 次要数据文件用于存储用户数据和索引 在可能的情况下 主数据文件和次要数据文件可以单独存放在不同的磁盘上以分散I/O
如果采用多个数据文件 推荐主数据文件存储系统数据 次要数据文件存放用户数据和索引 这样会有助于提高I/O性能
利用文件组改善性能
在大型数据库系统中 可以考虑建立文件组来管理数据文件 将表和索引通过存放在不同的物理磁盘上进行性能监控比较 最后得出优化的存储方案
重视自动增长和自动收缩可能导致的性能问题
数据库文件的自动增长和自动收缩功能对于小型数据库的管理十分有用 但可能导致大型数据库的性能问题 因为文件的自然增长的同时会导致存储碎片的发生 当文件空间变大时 新分配的空间不一定和原来的空间连续 当文件空间收缩时 释放了部分空间 然而当文件又需要增长存储空间却不能利用原先释放的空间 也会导致碎片的发生
分离系统数据和用户数据
将系统数据库和用户数据库分开存放在不同的物理磁盘上有助于改善I/O性能 有助于数据库备份和恢复
优化索引设计
索引的设计对数据库的性能十分重要 具体不再阐述 可参见本博相关文章
定期更新统计信息
SQLServer默认使用基于代价的优化 所以统计信息的及时更新对于查询优化十分重要
定期的一致性检查
lishixin/Article/program/SQLServer/201311/22434
Ⅵ 如何利用索引提高SQLServer数据处理的效率
在良好的数据库设计基础上，能有效地使用索引是SQL Server取得高性能的基础，SQL Server采用基于代价的优化模型，它对每一个提交的有关表的查询，决定是否使用索引或用哪一个索引。因为查询执行的大部分开销是磁盘I/O，使用索引提高性能的一个主要目标是避免全表扫描，因为全表扫描需要从磁盘上读表的每一个数据页，如果有索引指向数据值，则查询只需读几次磁盘就可以了。
所以如果建立了合理的索引，优化器就能利用索引加速数据的查询过程。但是，索引并不总是提高系统的性能，在增、删、改操作中索引的存在会增加一定的工作量，因此，在适当的地方增加适当的索引并从不合理的地方删除次优的索引，将有助于优化那些性能较差的SQL Server应用。实践表明，合理的索引设计是建立在对各种查询的分析和预测上的，只有正确地使索引与程序结合起来,才能产生最佳的优化方案。本文就SQL Server索引的性能问题进行了一些分析和实践。
一、聚簇索引(clustered indexes)的使用
聚簇索引是一种对磁盘上实际数据重新组织以按指定的一个或多个列的值排序。由于聚簇索引的索引页面指针指向数据页面，所以使用聚簇索引查找数据几乎总是比使用非聚簇索引快。每张表只能建一个聚簇索引，并且建聚簇索引需要至少相当该表120%的附加空间，以存放该表的副本和索引中间页。建立聚簇索引的思想是：
1、大多数表都应该有聚簇索引或使用分区来降低对表尾页的竞争，在一个高事务的环境中，对最后一页的封锁严重影响系统的吞吐量。
2、在聚簇索引下，数据在物理上按顺序排在数据页上，重复值也排在一起，因而在那些包含范围检查(between、<、<=、>、>=)或使用group by或order by的查询时，一旦找到具有范围中第一个键值的行，具有后续索引值的行保证物理上毗连在一起而不必进一步搜索，避免了大范围扫描，可以大大提高查询速度。
3、在一个频繁发生插入操作的表上建立聚簇索引时，不要建在具有单调上升值的列(如IDENTITY)上，否则会经常引起封锁冲突。
4、在聚簇索引中不要包含经常修改的列，因为码值修改后，数据行必须移动到新的位置。
5、选择聚簇索引应基于where子句和连接操作的类型。
聚簇索引的侯选列是：
1、主键列,该列在where子句中使用并且插入是随机的。
2、按范围存取的列，如pri_order > 100 and pri_order < 200。
3、在group by或order by中使用的列。
4、不经常修改的列。
5、在连接操作中使用的列。
二、非聚簇索引(nonclustered indexes)的使用
SQL Server缺省情况下建立的索引是非聚簇索引，由于非聚簇索引不重新组织表中的数据，而是对每一行存储索引列值并用一个指针指向数据所在的页面。换句话说非聚簇索引具有在索引结构和数据本身之间的一个额外级。一个表如果没有聚簇索引时,可有250个非聚簇索引。每个非聚簇索引提供访问数据的不同排序顺序。在建立非聚簇索引时，要权衡索引对查询速度的加快与降低修改速度之间的利弊。另外，还要考虑这些问题：
1、索引需要使用多少空间。
2、合适的列是否稳定。
3、索引键是如何选择的，扫描效果是否更佳。
4、是否有许多重复值。
对更新频繁的表来说，表上的非聚簇索引比聚簇索引和根本没有索引需要更多的额外开销。对移到新页的每一行而言，指向该数据的每个非聚簇索引的页级行也必须更新，有时可能还需要索引页的分理。从一个页面删除数据的进程也会有类似的开销，另外，删除进程还必须把数据移到页面上部，以保证数据的连续性。所以，建立非聚簇索引要非常慎重。非聚簇索引常被用在以下情况：
1、某列常用于集合函数(如Sum,....)。
2、某列常用于join,order by,group by。
3、查寻出的数据不超过表中数据量的20%。
三、覆盖索引(covering indexes)的使用
覆盖索引是指那些索引项中包含查寻所需要的全部信息的非聚簇索引，这种索引之所以比较快也正是因为索引页中包含了查寻所必须的数据,不需去访问数据页。如果非聚簇索引中包含结果数据,那么它的查询速度将快于聚簇索引。
但是由于覆盖索引的索引项比较多,要占用比较大的空间。而且update操作会引起索引值改变。所以如果潜在的覆盖查询并不常用或不太关键，则覆盖索引的增加反而会降低性能。
四、索引的选择技术
p_detail是住房公积金管理系统中记录个人明细的表，有890000行，观察在不同索引下的查询运行效果，测试在C/S环境下进行，客户机是IBM PII350(内存64M),服务器是DEC Alpha1000A(内存128M),数据库为SYBASE11.0.3。
1、 select count(*) from p_detail where
op_date>’19990101’ and op_date<’
19991231’ and pri_surplus1>300
2、 select count(*),sum(pri_surplus1) from p_detail
where op_date>’19990101’ and
pay_month between‘199908’ and’199912’
不建任何索引查询1 1分15秒
查询2 1分7秒
在op_date上建非聚簇索引查询1 57秒
查询2 57秒
在op_date上建聚簇索引查询1 <1秒
查询2 52秒
在pay_month、op_date、pri_surplus1上建索引查询1 34秒
查询2 <1秒
在op_date、pay_month、pri_surplus1上建索引查询1 <1秒
查询2 <1秒
从以上查询效果分析，索引的有无，建立方式的不同将会导致不同的查询效果，选择什么样的索引基于用户对数据的查询条件,这些条件体现于where从句和join表达式中。一般来说建立索引的思路是：
(1)主键时常作为where子句的条件，应在表的主键列上建立聚簇索引，尤其当经常用它作为连接的时候。
(2)有大量重复值且经常有范围查询和排序、分组发生的列，或者非常频繁地被访问的列，可考虑建立聚簇索引。
(3)经常同时存取多列，且每列都含有重复值可考虑建立复合索引来覆盖一个或一组查询，并把查询引用最频繁的列作为前导列，如果可能尽量使关键查询形成覆盖查询。
(4)如果知道索引键的所有值都是唯一的，那么确保把索引定义成唯一索引。
(5)在一个经常做插入操作的表上建索引时，使用fillfactor(填充因子)来减少页分裂，同时提高并发度降低死锁的发生。如果在只读表上建索引，则可以把fillfactor置为100。
(6)在选择索引键时，设法选择那些采用小数据类型的列作为键以使每个索引页能够容纳尽可能多的索引键和指针，通过这种方式，可使一个查询必须遍历的索引页面降到最小。此外，尽可能地使用整数为键值，因为它能够提供比任何数据类型都快的访问速度。
五、索引的维护
上面讲到,某些不合适的索引影响到SQL Server的性能,随着应用系统的运行,数据不断地发生变化,当数据变化达到某一个程度时将会影响到索引的使用。这时需要用户自己来维护索引。索引的维护包括：
1、重建索引
随着数据行的插入、删除和数据页的分裂，有些索引页可能只包含几页数据，另外应用在执行大块I/O的时候，重建非聚簇索引可以降低分片，维护大块I/O的效率。重建索引实际上是重新组织B-树空间。在下面情况下需要重建索引：
(1)数据和使用模式大幅度变化。
(2)排序的顺序发生改变。
(3)要进行大量插入操作或已经完成。
(4)使用大块I/O的查询的磁盘读次数比预料的要多。
(5)由于大量数据修改，使得数据页和索引页没有充分使用而导致空间的使用超出估算。
(6)dbcc检查出索引有问题。
当重建聚簇索引时，这张表的所有非聚簇索引将被重建。
2、索引统计信息的更新
当在一个包含数据的表上创建索引的时候，SQL Server会创建分布数据页来存放有关索引的两种统计信息：分布表和密度表。优化器利用这个页来判断该索引对某个特定查询是否有用。但这个统计信息并不动态地重新计算。这意味着，当表的数据改变之后，统计信息有可能是过时的，从而影响优化器追求最有工作的目标。因此，在下面情况下应该运行update statistics命令：
(1)数据行的插入和删除修改了数据的分布。
(2)对用truncate table删除数据的表上增加数据行。
(3)修改索引列的值。
六、结束语
实践表明，不恰当的索引不但于事无补，反而会降低系统的执行性能。因为大量的索引在插入、修改和删除操作时比没有索引花费更多的系统时间。例如下面情况下建立的索引是不恰当的：
1、在查询中很少或从不引用的列不会受益于索引，因为索引很少或从来不必搜索基于这些列的行。
2、只有两个或三个值的列，如男性和女性(是或否)，从不会从索引中得到好处。
另外，鉴于索引加快了查询速度，但减慢了数据更新速度的特点。可通过在一个段上建表，而在另一个段上建其非聚簇索引，而这两段分别在单独的物理设备上来改善操作性能。
Ⅶ 如何做SqlServer 数据查询优化！
一、建立索引
二、建立存储过程
三、只查询您所需要的数据，不要把所有数据都查询出来，防止数据冗余。
四、对于大量及海量数据一般还要建立分区
Ⅷ 如何查表是否有索引 sqlserver
1、本文以表pi_content为例，相应的字段为（[piid] int, [seqnum] int,[phname] nvarchar(50),[content] nvarchar(MAX)），数据量为百万级。
Ⅸ sqlserver中这样的字段用什么索引比较好
1、关于索引：数据量不是特别大的情况下，建议不要用索引。因为索引本身也是一种数据，随着数据的变化，系统也需要维护索引的变动，这需要开销。不仅仅是空间上的开销，还有处理时间的开销。根据经验，在SQL Server类型的数据表上，如果数据只有几万条，不建索引，让系统全表扫描，并不会比有索引慢多少，有时甚至更快。
2、索引的类别：索引有唯一索引和非唯一索引，还有你说的聚集与非聚集。唯一索引顾名思义，就是该索引字段所有的值不能重复。对于非唯一索引，允许索引字段为空。想来聚集的意思你也是懂的了。在一个表上，只能有一个聚集索引。一般聚集索引建立在主键上比较好。根据经验，聚集对数据访问性能的改善很有限，考虑到聚集对数据变动的性能影响，有时候不建聚集索引，使用唯一索引是非常不错的选择。
3、关于你这个表，要看username是个什么属性的字段。根据上述，如果你的数据只有几千条，没必要在这个字段上使用索引。如果数据量上十万，且是唯一值，最多建一个唯一索引即可。可以自己观察一下，有索引、与没有的时候，性能究竟如何。
Ⅹ 如何提高SQL Server大数据条件下的查询速度
1.关于索引优化
建索引的选择必须结合SQL查询、修改、删除语句的需要，一般的说法是在WHERE里经常出现的字段建索引。如果在WHERE经常是几个字段一起出现而且是用AND连接的，那就应该建这几个字段一起的联合索引，而且次序也需要考虑，一般是最常出现的放前面，重复率低的放前面。
SQL
Server提供了一种简化并自动维护数据库的工具。这个称之为数据库维护计划向导（Database
Maintenance
Plan
Wizard
，DMPW）的工具也包括了对索引的优化。如果你运行这个向导，你会看到关于数据库中关于索引的统计量，这些统计量作为日志工作并定时更新，这样就减轻了手工重建索引或者DBCC
INDEXDEFRAG所带来的工作量。如果你不想自动定期刷新索引统计量，你还可以在DMPW中选择重新组织数据和数据页，这将停止旧有索引并按特定的填充因子重建索引。
2.
改善硬件（双CPU，Raid
5，增加内存）
tempdb这个临时数据库，它对性能的影响较大。tempdb和其他数据库一样可以增大，可以缩小。当数据文件需要增长的时候，通常不能保持剩余部分的连续性。这时文件就会产生碎片，这种碎片会造成性能下降。这种碎片属于外来性碎片。要阻止在tempdb中产生外来性碎片，必须保证有足够的硬盘空间。一般将tempdb的容量放到平均使用容量。而你也应该允许tempdb自动增长，比如你有个一个超大的join操作，它建立了一个超过tempdb容量的时候，该查询将失败。你还要设置一个合理的单位增长量。因为如果你设得太小，将会产生许多外来性碎片，反而会占用更多资源。sqlserver调优最有效的做法之一，就是把争夺资源的操作独立出去。tempdb就是一个需要独立出去的部分而tempdb和其他系统库一样是公用的，是存取最可能频繁的库，所有处理临时表、子查询、GROUP
BY、排序、DISTINCT、连接等等。它最适合放到一个具有快速读写能力的设备上。比如RAID0卷或RAID0+1卷上。
查询语句一定要使用存储过程；
3、查询尽量使用TOP子句
4.将表按一定的约束分成子表,(如按分类)创建约束,在用Like
时,先用分类
and
like
,
应该可能解决问题.
而且效果立秆见影!(你要确定SQL会认识你建的分区视图).我一个表有上百万的记录(700兆),用分区视图后,查询速度基本跟10万行一样.
如果还是太慢,还可以考滤分布式分区视图!这总可以解决问题了吧!
关键在于你能否把大表按某种约束分解成子表.