我认为用exists 与用in 的性能是相同的. 但是有个朋友说不是, 我写了下面两个语句. 发现它们的query cost 都是相同的,这是否足以证明我

Question

in 和 exists一般都不会相同,exists的效率通常高于in

Answer 1

像你目前这种情况，应该是Exists比In的效率高，晚上我再做做测试。

Answer 2

exits 比IN要好,一般情况下.
通常你多写点,多测点就可以了

Answer 3

exists:是测试条件是否条件。
如果后面测试条件存在，则执行前面的检索语句，否则显示空结果集。
象你这道题
SELECT location_id  FROM t_stored_item sto WHERE item_id = 'I1' AND  exists 
 (SELECT location_id  FROM t_location   WHERE type = 'LI' and .location_id=location_id)
ORDER BY location_id
 它的执行过程我认为是这样的，如果exists括号内的type = 'LI' 的记录，则显示括号名的检索结果。否则，显示空结果集，对吗。而这个:
SELECT location_id FROM t_stored_item sto WHERE item_id = 'I1' AND  location_id in    (SELECT location_id   FROM t_location   WHERE type = 'LI' )  ORDER BY location_id
语句是一个嵌套查询,in在此是做为一个查询条件，查找满足type = 'LI' 这个条件的记录的
location_id   有哪些，并同时满足　item_id = 'I1' 这个条件，返回检索结果。所以exists　和 in　是不同的

Answer 4

exists高於in這當然是在數據量多且存在表之間的聯連。樓主你試試兩個表都是幾百萬的數據相關連的情況。
這個我測試過是exists高

Answer 5

   
   
When coding a SQL statement with tables in master-detail relationships, it's common to have to decide whether to write the query using the WHERE EXISTS (. . .) clause or the WHERE value IN (. . .) clause. You may resist using WHERE EXISTS because it has the awkward syntax of returning a value, which you always ignore. However, there's a difference when using rule-based optimization. You can determine the performance of a rule-based query by understanding which table is the driving table and how many rows each part returns. When you write a query using the IN clause, you're telling the rule-based optimizer that you want the inner query to drive the outer query (think: IN = inside to outside). For example, to query the 14-row EMP table for the direct reports to the employee KING, you could write the following: select ename from emp e 
    where mgr in (select empno from emp where ename = 'KING'); Here's the EXPLAIN PLAN for this query: OBJECT     OPERATION 
---------- ---------------------------------------- 
                 SELECT STATEMENT() 
                  NESTED LOOPS() 
EMP                TABLE ACCESS(FULL) 
EMP                 TABLE ACCESS(BY INDEX ROWID) 
PK_EMP               INDEX(UNIQUE SCAN) This query is virtually equivalent to this: select e1.ename from emp e1,(select empno from emp where ename = 'KING') e2 
    where e1.mgr = e2.empno; You can write the same query using EXISTS by moving the outer query column to a subquery condition, like this: select ename from emp e 
    where exists (select 0 from emp where e.mgr = empno and ename = 'KING'); When you write EXISTS in a where clause, you're telling the optimizer that you want the outer query to be run first, using each value to fetch a value from the inner query (think: EXISTS = outside to inside). The EXPLAIN PLAN result for the query is: OBJECT     OPERATION 
---------- ---------------------------------------- 
                 SELECT STATEMENT() 
                  FILTER() 
EMP                TABLE ACCESS(FULL) 
EMP                 TABLE ACCESS(BY INDEX ROWID) 
PK_EMP               INDEX(UNIQUE SCAN) This is virtually similar to the PL/SQL code: set serveroutput on; 
declare 
    l_count integer; 
begin 
    for e in (select mgr,ename from emp) loop 
        select count(*) into l_count from emp 
         where e.mgr = empno and ename = 'KING'; 
        if l_count != 0 then 
            dbms_output.put_line(e.ename); 
        end if; 
    end loop; 
end; To determine which clause offers better performance in rule-based optimization, consider how many rows the inner query will return in comparison to the outer query. In many cases, EXISTS is better because it requires you to specify a join condition, which can invoke an INDEX scan. However, IN is often better if the results of the subquery are very small. You usually want to run the query that returns the smaller set of results first. Some people avoid the EXISTS clause because of the requirement to return a result from the query--even though the result is never used. Depending on personal style, people often use 'X,' 1, 0, or null. From looking at the EXPLAIN PLAN output, it appears that the optimizer throws out whatever value you enter and uses 0 all the time. Many developers get into the habit of always entering some constant value. If you want to run your own tests, or see other examples, here are the two scripts I used: REM -- explain.sql - view plan from PLAN_TABLE 
set feedback off 
set verify off 
set pages 2000 
column operation format a40 
column object format a10 TTITLE * STATEMENT_ID = '&1' * 
select object_name object, 
       lpad(' ',level-1)||operation||'('||options||')' operation 
  from plan_table 
 start with id = 0 and statement_id = '&1' 
 connect by prior id = parent_id and statement_id = '&1'; And: REM -- exists.sql - examples with EXPLAIN PLAN 
REM -- IN vs. EXISTS REM -- if you don't have a PLAN_TABLE, run ... 
REM -- @?/rdbms/admin/xplan 
alter session set optimizer_goal = rule; 
truncate table plan_table; REM -- find direct reports to KING 
explain plan set statement_id = 'IN' for 
select ename from emp e 
    where mgr in (select empno from emp where ename = 'KING'); explain plan set statement_id = 'JOIN-IN' for 
select e1.ename from emp e1,(select empno from emp where ename = 'KING') e2 
    where e1.mgr = e2.empno; explain plan set statement_id = 'EXISTS' for 
select ename from emp e 
    where exists (select 0 from emp where e.mgr = empno and ename = 'KING'); explain plan set statement_id = '=' for 
select ename from emp e 
    where mgr = (select empno from emp where ename = 'KING'); explain plan set statement_id = 'JOIN1' for 
select e1.ename from emp e1,emp e2 
 where e1.mgr = e2.empno 
   and e2.ename = 'KING'; REM -- find employees with greater than average salaries 
explain plan set statement_id = '>' for 
select ename from emp e where e.sal > (select avg(sal) from emp); explain plan set statement_id = 'JOIN2' for 
select e1.ename from emp e1,(select avg(sal) sal from emp) e2 
 where e1.sal > e2.sal;  

Answer 6

exists关心有无匹配记录存在,匹配到第一个后便停止内表遍历.
in    关心有多少条匹配记录,因此存在对内表的全局遍历.