高效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 页物理存储）最右的叶节点上（如上例）。
相关文档：
一、 PL/SQL语言简介
(本讲义之所有程序均调式通过)
首先我们看一个简单之例子,下面这个例子是统计从1至100的总和.
declare
i number:=0; /*声明变量井给初值*/
t number:=1;
error_message exception; /*声明一个出错处理*/
begin
......
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',
......
给你个最详细的吧 可能有你要的内容
锁的概述
一. 为什么要引入锁
多个用户同时对数据库的并发操作时会带来以下数据不一致的问题:
丢失更新
A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果,比如订票系统
脏读
A用户修改了数据,随后B用户又读出该数据,但A用户因为某些原因取� ......
-- 示例一, 使用证书加密数据.
-- 建立测试数据表
CREATE TABLE tb(ID int IDENTITY (1,1),data varbinary (8000));
GO
-- 建立证书一, 该证书使用数据库主密钥来加密
CREATE CERTIFICATE Cert_Demo1
WITH
SUBJECT = N'cert1 encryption by database master key' ,
START_DATE = ......
今天做SQL 优化，查找执行计划时，执行计划，发现此执行计划与以往的计划有所区别；找录互联网，终于找一篇有关研究比较深入的文章；
原执行计划使用的是索引扫描，突然一下会使用索引覆盖技术，效率大增；
SELECT * 的真相：索引覆盖(index coverage)
SELECT *的效率很糟糕吗？当然，所有人都知道这一点，但是为什么 ......
