EXISTS and NOT EXISTS do the same work: the db engine only has to find a single row that matches the WHERE clause in the subquery to satisfy the test. The syntax gives it aways: NOT EXISTS is the logical NOT of the EXISTS test.

Depending on the subquery WHERE condition the existence of at least one matching row may be answered by scanning an index, or it may require a table scan. In either case as soon as a single matching row is found the result of EXISTS is known. The result of NOT EXISTS is simply the logical inverse of the result of EXISTS.

In your example the subquery inside the EXISTS() doesn’t “return approx. 1 million rows.” It doesn’t return any rows — it returns a TRUE or FALSE. The db engine can give the result when it encounters the first row matching the WHERE clause. There is no result set to discard for the subquery.

If you are seeing different results using SELECT 1 vs. SELECT * it’s probably due to SELECT * having done all the work and cached the indexes so SELECT 1 has less work to do.

The Microsoft SQL Server documentation says this:

“The select list of a subquery introduced with EXISTS, by convention, has an asterisk (*) instead of a single column name. The rules for a subquery introduced with EXISTS are the same as those for a standard select list, because a subquery introduced with EXISTS creates an existence test and returns TRUE or FALSE, instead of data.” (T-SQL reference, Subquery Rules).

Anyone who knows SQL should recognize the idiom EXISTS(SELECT * …). The alternative EXISTS(SELECT 1 …) is obvious but not really idiomatic. Anything else is just showing off and making the SQL harder for the next person to understand.

Regards,
Palanisamy

select * from table1 a
where (a.x, a.y) in (
select b.x, min(b.y)
from table1 b
group by b.x
)

I’m wondering what test conditions you used…

The other day I had a performance issue with a proceudre that included a statement like

IF NOT EXISTS (SELECT * FROM view WHERE condition)

The view itself based on two tables withe several 10-thousand rows in one and several million in the other (as to my best knowledge properly joined and indexed using information from STATISTICS XML). The SELECT statement above would return approx. 1 million rows.

When I changed it to SELECT 1, performance increased significantly.

My explanation (at least to myself) goes a little more in direction of boolean logic:

The NOT EXISTS statement becomes FALSE performing the following tasks:
SELECT * -> grab all the data and if there are any drop them and return FALSE
SELECT 1 -> try to grab the first row and if you find one single row return FALSE, no matter on how many rows fulfill the WHERE clause

As far as I figured the TRUE statement takes the same time for both, * amd 1, since the resultset is NULL in both cases.

Would you agree with my comment and, if not, retest your code with large tables?

Regards

Lutz

I managed to get a glimpse using the following two queries. According the estimated query execution plans the ’select *’ query has an extra step and the estimated row size is larger than ’select 1′. Perhaps this is not proof but I think it is more evidence that ’select 1′ is the better practice.

select * from tempdb.sys.sysobjects where [name] = ”

select 1 from tempdb.sys.sysobjects where [name] = ”

SELECT rnum, employee_id
FROM (
SELECT rownum rnum, employee_id
FROM employees
WHERE ROWNUM < 100)
WHERE rnum BETWEEN 2 AND 12;

this query will retrieve output for
record 2 until record 12. By use of inline view.

Regards,
Ravi
Sony India
____________________
Hi,

Just want to ask, is there any select statement whereby it will call you to select the record start from second record then additional 10 records onwards?

For example,

User have to retrieve record 2 until record 12?
If yes, can help?

Thanks.

Just want to ask, is there any select statement whereby it will call you to select the record start from second record then additional 10 records onwards?

For example,

User have to retrieve record 2 until record 12?
If yes, can help?

Thanks.

Good comment. I think there is no real conclusion. As I said I always used SELECT 1, however this whole exercise is for fun and what everybody think about this matter.

I like your way of thinking however neither theory is proven yet. I am also curious what other readers have to suggest.

Regards,
Pinal Dave ( http://www.SQLAuthority.com )

People have been saying for a long time that SELECT * in an exists condition has unneeded overhead – and there are several blog posts out there to back up that claim.

If you really really want to use SELECT * instead of using SELECT 1 in production code – then go ahead.

If you haven’t seen performance issues with your code then don’t worry about it.

I understand that you want something tangible to look at and prove or disprove this “theory”, but I don’t have time to put the code together and gather the statistics just to satisfy curiosity.

I’ll leave that up to you to prove or disprove.

It may be a good idea to post a comment on Connor’s site asking if he can prove or disprove this – as he is more intimate with the query processor than I am.

We can not take anybodies word for it. (With due respect to Conor – I know he is the man). Is there any proof for this?

-Guy

“The * will be expanded to some potentially big column list and then it will be determined that the semantics of the EXISTS does not require any of those columns, so basically all of them can be removed.

“SELECT 1″ will avoid having to examine any unneeded metadata for that table during query compilation.”

Source : http://www.sqlskills.com/blogs/conor/2008/02/07/EXISTSSubqueriesSELECT1VsSELECT.aspx