11.分页1.
select * from (select top 2 * from( select top 3 * from t_table order by field1) a order by field1 desc) b order by field1
10.
row_number函数的用途是非常广泛，这个函数的功能是为查询出来的每一行记录生成一个序号。row_number函数的用法如下面的SQL语句所示：
row_number必须和over(order by field1)一起使用！
9.
聚集索引和非聚集索引的根本区别是表记录的排列顺序和与索引的排列顺序是否一致
，聚集索引表记录的排列顺序与索引的排列顺序一致，优点是查询速度快，因为一旦
具有第一个索引值的纪录被找到，具有连续索引值的记录也一定物理的紧跟其后。
聚集索引的缺点是对表进行修改速度较慢，这是为了保持表中的记录的物理顺序与索
引的顺序一致，而把记录插入到数据页的相应位置，必须在数据页中进行数据重排，
降低了执行速度。建议使用聚集索引的场合为：
a.此列包含有限数目的不同值；
b.查询的结果返回一个区间的值；
c.查询的结果返回某值相同的大量结果集。
非聚集索引指定了表中记录的逻辑顺序，但记录的物理顺序和索引的顺序不一致
，聚集索引和非聚集索引都采用了B+树的结构，但非聚集索引的叶子层并不与实际的
数据页相重叠，而采用叶子层包含一个指向表中的记录在数据页中的指针的方式。非
聚集索引比聚集索引层次多，添加记录不会引起数据顺序的重组。建议使用非聚集索
引的场合为：
a.此列包含了大量数目不同的值；
b.查询的结束返回的是少量的结果集；
c.order by 子句中使用了该列。
--不用索引查询
Select * FROM IndexTestTable WHIT(INDEX(0))
Where Status='B'
--创建聚集索引
Create CLUSTERED INDEX icIndexTestTable
ON IndexTestTable(Status)
GO
--使用索引查询
Select * FROM IndexTestTable WITH(INDEX(icIndexTestTable))
Where Status='B'
表中经常有一个列或列的组合，其值能唯一地标识表中的每一行。这样的一列或多列
称为表的主键.(默认为聚集索引)
聚集索引确定表中数据的物理顺序。聚集索引类似于电话簿，后者按姓氏排列数
据。由于聚集索引规定数据在表中的物理存储顺序，因此一个表只能包含一个聚集索
引。但该索引可以包含多个列（组合索引），就像电话簿按姓氏和名字进行组织一样
。
非聚集索引与课本中的索引类似。数据存储在一个地方，索引存储在另一个地方
，索引带有指针指向数据的存储位置。索引中的项目按索引键值的顺序存储，而表中
的信息按另一种顺序存储（这可以由聚集索引规定）。
如果在表中未创建聚集索引，则无法保证这些行具有任何特定的顺序。
聚集索引..就像我们新华字典中的按拼音排序..即你查.."爱"字..可以在前面看到"
癌"字...但不你不在前后页中看到"受"字..
而非聚集索引..就是新华字典中的按部首..笔划排序...
聚集索引相当于我们书本上前面的目录的一样，它可以方便快速的找到你想找的内容
，而非聚集索引就相当于书最后几页的解释，它是对书中某个语句或者是生词的解释
，就像我们上学时候的地理说一样，书后面都有各种地理名称的英文解释；
《数据库原理》里面的解释：聚集索引的顺序就是数据的物理存储顺序，而非聚集索
引的顺序和数据物理排列无关。因为数据在物理存放时只能有一种排列方式，所以一
个表只能有一个聚集索引。
在SQL SERVER中，索引是通过二叉树的数据结构来描述的；我们可以如此理解这个两
种索引：聚集索引的叶节点就是数据节点，而非聚集索引的叶节点仍然是索引节点，
只不过其包含一个指向对应数据块的指针。
聚集索引会降低 insert，和update操作的性能，所以，是否使用聚集索引要全面
衡量。
8.
写一个存储过程。大家知道SQL SERVER的存储过程是事先编译好的SQL语句，它的执行效率要比通过WEB页面传来的SQL语句的执行效率要高。
7.
如何实现从大容量的数据库中快速地查询出您所需要的数据方法。当然，我们介绍的这些方法都是“软”方法，在实践中，我们还要考虑各种“硬”因素，如：网络性能、服务器的性能、操作系统的性能，甚至网卡、交换机等。
6.
order by按聚集索引列排序效率最高
影响数据库响应时间最大的因素是物理I/O操作。而限制物理I/O操作此处的最有效方法之一就是使用TOP关键词了。TOP关键词是SQL SERVER中经过系统优化过的一个用来提取前几条或前几个百分比数据的词。经笔者在实践中的应用，发现TOP确实很好用，效率也很高。
聚集索引是如此的重要和珍贵，所以笔者总结了一下，一定要将聚集索引建立在：
1、您最频繁使用的、用以缩小查询范围的字段上;
2、您最频繁使用的、需要排序的字段上。
非
聚集索引比聚集索引层次多，添加记录不会引起数据顺序的重组。
5.
通配符%在字符串的开头使得索引无法使用；
字段提取要按照“需多少、提多少”的原则，避免“select *”；
4.
select * from table1 where name='zhangsan' and tID > 10000
和执行:
select * from table1 where tID > 10000 and name='zhangsan'
SQL SERVER中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。
3.
不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。
对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。
2.
在进行数据查询时都离不开字段的是“日期”还有用户本身的“用户名”。
既然这两个字段都是如此的重要，我们可以把他们合并起来，
建立一个复合索引(compound index)。
而如果仅用复合聚集索引的非起始列作为查询条件的话，这个索引是不起任何作用的。
如果复合索引的所有列都用上，而且查询结果少的话，这样就会形成“索引覆盖”，因而性能可以达到最优。同时，请记住：无论您是否经常使用聚合索引的其他列，但其前导列一定要是使用最频繁的列。
索引有助于提高检索性能，但过多或不当的索引也会导致系统低效。过多的索引甚至会导致索引碎片。
索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。
1.
默认sql会自动在主键上建立 聚集索引 的误区：
1）如果数据量很大很大，那么因为插入数据造成的 聚集索引的维护开销 就会变得很大，而 非聚集索引不存在此事
2）如果默认对ID进行加 聚集索引，但是很多时候ID是自增的，对于 实际上ID查询用的不是很多，所以可能会浪费 每个表只能建立一个聚集索引以及聚集索引本身的 资源。
(1)仅在主键上建立聚集索引，并且不划分时间段： Select gid,fariqi,neibuyonghu,title from tgongwen 用时：128470毫秒(即：128秒) (2)在主键上建立聚集索引，在fariq上建立非聚集索引： select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi> dateadd(day,-90,getdate()) 用时：53763毫秒(54秒) (3)将聚合索引建立在日期列(fariqi)上： select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi> dateadd(day,-90,getdate()) 用时：2423毫秒(2秒) 虽然每条语句提取出来的都是25万条数据，各种情况的差异却是巨大的，特别是将聚集索引建立在日期列时的差异。事实上，如果您的数据库真的有1000万容量的话，把主键建立在ID列上，就像以上的第1、2种情况，在网页上的表现就是超时，根本就无法显示。这也是我摒弃ID列作为聚集索引的一个最重要的因素。
