高效SQL查询之索引（I）
大型系统的生产环境，一般情况下，我们评价一条查询是否有效率，更多的是关注逻辑 IO( 至于为什么，回头补一篇 ) 。我们常说，“要建彪悍的索引”、“要写高效的 SQL ”，其实最终目的就是在相同结果集情况下，尽可能减少逻辑 IO 。
1.1 where 条件的列上都得有统计信息。
没统计信息 SQLServer 就无法估算不同查询计划开销优劣，而只能采用最稳妥的 Scan （不管是 table scan 还是 clustered index scan ）。一般情况下我们不会犯这种错误—— where 条件里不使用非索引列是个常识。索引上的统计信息是无法删除的。
1.2 尽量不使用不等于（ != ）或者 NOT 逻辑运算符。
这条规则被广为传颂，原因据联机文档和百敬同学的书讲，也是 SQLServer 无法评估不同查询计划开销的优劣。但是 SqlServer2k5 聪明了很多，试验发现尽管用了 != 或者 not ，查询还是会被优化。如下：
create table tb1
(
col1 int identity ( 1, 1) primary key ,
col2 int not null,
col3 varchar ( 64) not null
)
create index ix_tb1_col2 on tb1
(
col2
)
create index ix_tb1_col3 on tb1
(
col3
)
declare @f int
set @f = 0
while @f < 9999
begin
insert into tb1 ( col2, col3) values ( 1, 'ssdd' ）
set @f = @f + 1
end
insert into tb1 ( col2, col3) values ( 0, 'aadddd' )
insert into tb1 ( col2, col3) values ( 2, 'bbddd' )
insert into tb1 ( col2, col3) values ( 3, 'bbaaddddddaa' )
通过上述代码，各位可以看到数据分布。 col2 值为 1 的有 9999 条； col2 值为 0 、 2 、 3 的分别有 1 条。
按照本条规则， != 和 NOT 带来的应该是个 scan 操作，但实际情况是：
SQL2k5 很聪明，它依据统计信息分析得出来，应该采用 index seek 而不是 index scan 。（稍微解释解释 index seek 和 index scan ：索引是一颗 B 树， index seek 是查找从 B 树的根节点开始，一级一级找到目标行。 index scan 则是从左到右，把整个 B 树遍历一遍。假设唯一的目标行位于索引树（假设是非聚集索引，树深度 2 ，叶节点占用 k 页物理存储）最右的叶节点上（如上例）。
相关文档：
sql 2005表的复制有两种：一种就是把整个表复制过去，就好像复制文件并且重命名。别外一种就是把表的内容复制过出.
select * into newtable form oldtable;把oldtabel复制到newtable且newtable不存在,否则出错.;
insert into newtable select * from oldtable把oldtable的内容插入到newtable, newtable一定要存在, ......
下载地址：http://msftdbprodsamples.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=19353
我下载的是SQL2008.AdventureWorks_All_Databases.x86.msi，本不想下载这种安装文件，但脚本文件总是执行出错，原因没具体深究。这种安装文件安装后会创建六个库AdventureWorks、AdventureWorks2008、AdventureWorksDW、Ad ......
给你个最详细的吧 可能有你要的内容
锁的概述
一. 为什么要引入锁
多个用户同时对数据库的并发操作时会带来以下数据不一致的问题:
丢失更新
A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果,比如订票系统
脏读
A用户修改了数据,随后B用户又读出该数据,但A用户因为某些原因取� ......
第一步, 在收缩前先查看日志的大小:
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
************ ......
