高效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 * 返回的结果到你的应用程序中将会在结构上发生变化。良好的应用程序应该是使用字段名称的，而不应该受此影响。当外界发生变化时，良好的应用程序设计也应该最小化的更改。
相关文档：
sql 2005表的复制有两种：一种就是把整个表复制过去，就好像复制文件并且重命名。别外一种就是把表的内容复制过出.
select * into newtable form oldtable;把oldtabel复制到newtable且newtable不存在,否则出错.;
insert into newtable select * from oldtable把oldtable的内容插入到newtable, newtable一定要存在, ......
USE MASTER
GO
--创建数据库文件存放目录
EXEC XP_CMDSHELL 'MKDIR D:\LOANSTUMIS'
IF EXISTS(SELECT *
from SYSDATABASES
WHERE NAME = 'LOANSTU')
DROP DATABASE LOANSTU
GO
--创建数据库
CREATE DATABASE LOANSTU
ON
(
NAME = 'LOANSTU_DATA',
FILENAME = 'D:\LOANSTUMIS\LOANSTU_DATA.MDF',
......
转自：http://hi.baidu.com/cszoo/blog/item/2439a5f517c19c2dbc31093c.html
（1）
SELECT
表名=case when a.colorder=1 then d.name else '' end,
表说明=case when a.colorder=1 then isnull(f.value,'') else '' end,
字段序号=a.colorder,
字段名=a.name,
标识=case when COLUMNPROPERTY( a.id,a.name,' ......
第一步, 在收缩前先查看日志的大小:
SELECT *
from sysfiles
WHERE name LIKE ' % LOG %'
GO
第二步, 把数据库的恢复模式设成”简单”:
ALTER DATABASE 库名 SET RECOVERY SIMPLE
GO
第三步, 运行checkpoint指令, 把dirty page写进数据库:
CHECKPOINT
GO
第四步, 截断日志:
BACKUP ......
作中数据库经常出错死锁，并且还要要求解决当前的死锁，问题多多；
参照CSDN，中国风(Roy)一篇死锁文章并改进了下；
/***********************************************************************************************************************
整理人：黑木崖上的蜗牛(lenolotus) 日期:2009.04.28
************ ......
