SQL中exists和in的区别
假设如下应用：
两张表——用户表TDefUser（userid，address,phone）和消费表TAccConsume(userid,time,amount)，需要查消费超过5000的用户记录。
用exists:
select * from TDefUser
where exists (select 1 from TAccConsume where TDefUser.userid=TAccConsume.userid and TAccConsume.amount>5000)
用in:
select * from TDefUser
where userid in (select userid from TAccConsume where TAccConsume.amount>5000)
通常情况下采用exists要比in效率高。
////
exists()后面的子查询被称做相关子查询 他是不返回列表的值的.只是返回一个true或false的结果(这也是为什么子查询里是"select 1"的原因，换成"select 6"完全一样，当然也可以select字段，但是明显效率低些)
其运行方式是先运行主查询一次（先得出主查询的结果） 再根据主查询中的每一行去子查询里去查询与其对应的结果.如果是true则输出,反之则不输出.
in()后面的子查询 是返回结果集的,换句话说执行次序和exists()不一样.子查询先产生结果集,然后主查询再去结果集里去找符合要求的字段列表去.符合要求的输出,反之则不输出.
（第一次查询找出>5000的结果，第二次查询判断userid是否在结果中）
////
比如用户表TDefUser（userid，address,phone），消费表TAccConsume(userid,time,amount)数据如下：
消费表聚集索引是userid,time
数据（注意因为有聚集索引,实际存储也是按以下次序的）
1 2006-1-1 200
1 2006-1-2 300
1 2006-1-2 500
1 2006-1-3 2000
1 2006-1-3 2000
1 2006-1-4 400
1 2006-1-5 500
2 2006-1-1 200
2 2006-1-2 300
2 2006-1-2 500
2 2006-1-3 2000
2 2006-1-3 6000
2 2006-1-4 400
2 2006-1-5 8000
3 2006-1-1 7000
3 2006-1-2 30000
3 2006-1-2 50000
3 2006-1-3 20000
语句：
select * from TDefUser
where exists (select 1 from TAccConsume where TDefUser.userid=TAccConsume.userid and TAccConsume.amount>5000)
对于userid=1，需要找所有记录，才
相关文档：
清除 SQL SERVER 2005 事务日志
１.右键在清除日志的数据库，如“TestDB”，点击[新建查询（Q）]
２.输入以下SQL语句，其中“TestDB”是数据库名称
DUMP TRANSACTION TestDB WITH NO_LOG
３.执行该SQL，成功后继续以下操作
４.右键该数据库节点，点击[任务（T）] -> [收缩（S）] -> [文件 ......
1.
用一条SQL
语句 查询出每门课都大于80
分的学生姓名
name kecheng fenshu
张三
语文 81
张三
数学 75
李四
语文 &nbs ......
前言：
sql_trace 是我在工作中经常要用到的调优工具，相比较statspack 我更愿意用这个工具。
因为数据库慢原因的85%以上是由于sql问题造成的，statspack没有sql的执行计划。显示没有它直观，方便，对想要针对性不强，
1，介绍数据库调优需要经常会用到的工具 ......
我先抛砖引玉:
1. 开发性: SQLSERVER不能,ORACLE能装在UNIX上
2. 分区表: SQLSERVER不� ......
以下是经测验能正确运行的:
create table t_emp_log212
(
who varchar2(10) not null,
action varchar2(10) not null,
actime date
);
create or replace trigger tri_emp_insert
before insert
on t_emp
begin
insert into t_emp_log(who,action,actime)values(user,'insert',sysdate);
end ......
