ORACLE中in 和 exists区别
IN和EXISTS区别
in 是把外表和内表作hash join，而exists是对外表作loop，每次loop再对内表进行查询。
一直以来认为exists比in效率高的说法是不准确的。
如果查询的两个表大小相当，那么用in和exists差别不大。
如果两个表中一个较小，一个是大表，则子查询表大的用exists，子查询表小的用in：
例如：表A（小表），表B（大表）
1：
select * from A where cc in (select cc from B)
效率低，用到了A表上cc列的索引；
select * from A where exists(select cc from B where cc=A.cc)
效率高，用到了B表上cc列的索引。
相反的
2：
select * from B where cc in (select cc from A)
效率高，用到了B表上cc列的索引；
select * from B where exists(select cc from A where cc=B.cc)
效率低，用到了A表上cc列的索引。
带in的关联子查询是多余的，因为in子句和子查询中相关的操作的功能是一样的。如：
select staff_name from staff_member where staff_id in
(select staff_id from staff_func where staff_member.staff_id=staff_func.staff_id);
为非关联子查询指定exists子句是不适当的，因为这样会产生笛卡乘积。如：
select staff_name from staff_member where staff_id
exists (select staff_id from staff_func);
not in 和not exists
如果查询语句使用了not in 那么内外表都进行全表扫描，没有用到索引；
而not extsts 的子查询依然能用到表上的索引。
所以无论哪个表大，用not exists都比not in要快。
尽量不要使用not in子句。使用minus 子句都比not in 子句快，虽然使用minus子句要进行两次查询：
select staff_name from staff_member where staff_id in (select staff_id from staff_member minus select staff_id from staff_func where func_id like '81%');
in 与 "=" 的区别
select name from student where name in ('zhang','wang','li','zhao');
与
select name from student where name='zhang' or name='li' or name='wang' or name='zhao'
的结果是相同的。
相关文档：
1
、安装前的准备
1.1
检查硬件
物理内存：
# grep
MemTotal /proc/meminfo
交换空间：
# grep
SwapTotal /proc/meminfo
交换空间的大小是根据物理内存的大小来设置的，物理内存少于
2G
的则交换空间设为物理内存的两倍，物理内存大于
2G
的则交换空间和物理内存大小一样。如果不符合上述规定，那么就需要 ......
在某些场合下，存储过程或触发器里的SQL语句需要动态生成。Oracle的DBMS_SQL包可以用来执行动态SQL语句。本文通过一个简单的例子来展示如何利用DBMS_SQL包执行动态SQL语句：
DECLARE
v_cursor NUMBER;
v_stat NUMBER;
& ......
在数据仓库环境中，我们通常利用物化视图强大的查询重写功能来提升统计查询的性能，但是物化视图的查询重写功能有时候无法智能地判断查询中一些相关联的条件，以至于影响性能。比如我们有一张销售表sales，用于存储订单的详细信息，包含交易日期、顾客编号和销售量。我们创建一张物化视图，按月存储累计销量信息，� ......
一：
使用Profile对用户Session会话进行资源限制
--但是如果使用了连接池之类的东东，就会出些问题，比如前台连接不上之类的
--http://www.eygle.com/archives/2008/10/profile_session_limit.html
sqlplus "/ as sysdba"
SQL> show parameter resource
SQL> alter system set resource_limit= ......
