-R

I still believe Greg Jorgensen was right on that one.

To be sure that a value DOESN’T exist, the engine must do a full scan. To be sure that a value exists, finding the first is enough. And if there is proper index, the scan will use it.

So, if you execute a WHERE X = 2 on a table completely filled of 1′s, a full scan will happen either way – doesn’t matter if you were using a EXISTS or a NOT EXISTS. The engine should work exactly the same way in both cases.

“EXISTS and NOT EXISTS do the same work”

This is not necessarily true. Depending on the indexes being used (or not used), an EXISTS may be faster, because it can stop as soon as it finds one matching row. A NOT EXISTS may have to table scan the entire table (if there’s no index that helps the query).

You need to have a valid backup in advance or you may need some third party tools

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.