高效SQL查询之索引覆盖(index coverage)
今天做SQL 优化，查找执行计划时，执行计划，发现此执行计划与以往的计划有所区别；找录互联网，终于找一篇有关研究比较深入的文章；
原执行计划使用的是索引扫描，突然一下会使用索引覆盖技术，效率大增；
SELECT * 的真相：索引覆盖(index coverage)
SELECT *的效率很糟糕吗？当然，所有人都知道这一点，但是为什么呢？
是因为返回了太多的数据？
这是一个普遍的回答，但我不这样认为。如果你的数据库设计规范合理，那么带宽占用实际上非常的小。
让我们看看下面的例子。下面的查询将会从AdventureWorks.dbo.TransactionHistoryArchive（总共大约有近9万行数据）中选择出326行数据。第一个使用了SELECT * 查询，后一个查询则有明确的字段。
SELECT * from Production.TransactionHistoryArchive
WHERE ReferenceOrderID < 100
SELECT ReferenceOrderLineID from Production.TransactionHistoryArchive
WHERE ReferenceOrderID < 100
在这种情况下，两者在网络带宽的区别只有15K（180K-165K），大约10%的带宽差异。的确值得去优化，但不会有很大的效果。
SELECT * 将造成表/索引扫描
SELECT * 的最大问题是将影响查询计划。SQL Server主要使用索引去查询你需要的数据，当索引包括所有的你请求查询的字段，SQL Server将不需要去在表中查询。这个概念称做索引覆盖。在上面的例子中，第一个查询结果是在聚集索引扫描中，反过来，第二个例子使用了更多更有效率的索引扫描。在这个案例中，索引扫描比聚集索引扫描快100倍 。
除非你已经将为每个字段建立了索引（显然不是个好主意），SELECT *是不能够利用到索引覆盖，你只能去做扫描操作（非常的没有效率）。
如果你只是查询你所需要的字段，那你更可能的覆盖到你的索引。我想这就是不推荐使用SELECT *的主要的原因。
稳定性方面
在维护一个应用程序时，SELECT *也会带来一些意想不大的问题。它会引起你的代码发生一些不确定性。如果你增加了一个行（译注：我觉得这里应该是字段）到一个表中，那么SELECT * 返回的结果到你的应用程序中将会在结构上发生变化。良好的应用程序应该是使用字段名称的，而不应该受此影响。当外界发生变化时，良好的应用程序设计也应该最小化的更改。
相关文档：
一、 PL/SQL语言简介
(本讲义之所有程序均调式通过)
首先我们看一个简单之例子,下面这个例子是统计从1至100的总和.
declare
i number:=0; /*声明变量井给初值*/
t number:=1;
error_message exception; /*声明一个出错处理*/
begin
......
方法(1)
SELECT stuff((select ','+ltrim(ColumnName) from #A for xml path('')
),1,1,'')
/*
102,103,104,105
*/
方法(2)
DECLARE @s NVARCHAR(1000)='';
SELECT @s+=ColumnName+',' from #A;
SELECT @s; ......
有时我们会像下面的情况一样，为主表的谋一条记录，在中间表(T_Stud_Course 表)中同时插入多条数据
T_Student 表
Stud_ID
Name
1
Tom
2
Jack
T_Course 表
Course_ID
Course
1
Chinese
2
English
T_Stud_Course 表
ID
Stud_ID
Course_ID
1
1
1
2
1
2
3
2
2
现在我们可以下面的存储过程� ......
SQL 2005 的存储过程和触发器调试大法（原创）
www.chengchen.net 程晨
昨天晚上我找遍了互联网也没有发现关于SQL2005存储过程和触发器的调试方法，研究到凌晨2点多钟，终于找到方法了，不干独享，拿出来分享。如果要转载，请保留版权，谢谢！
&nbs ......
本文演示了 SQL Server 2008 分区表实例;
1. 创建测试数据库 ；
2. 创建分区函数;
3. 创建分区架构;
4. 创建分区表;
5. 创建分区索引 ;
6. 分区切换 ;
7. 查询哪些表使用了分区表；
-- 作成者 leno
-- 日期: 2009-06-06 23:50:01.700
-- ......
