Link to home
Start Free TrialLog in
Avatar of AJS_Developer
AJS_Developer

asked on

SQL Server - Query Improvements for Uniqueidentifier tables

Hi There,

I have a table which has a Guid primary key. The table contains around 400,000 rows, and the expectation is that it will increase up into the low millions, depending on external factors.

The table has around 90 columns, two of which contain data i want to query by.

Basically, my query looks like the following:

Select * from table1
where col1 = @value or col2 = @value

At the moment, it takes around 35 seconds to retrieve all data (400,000 records), and around 1 second to for the above query to run using the temp variable @value (roughly 20,000 records)

What methods can i implement to improve the query performance? I currently have a nonclustered index on the primary key - should another index be added on col1 / col2?

Any ideas are appreciated. I can envision a query like this one day returning 400,000 records, and i want it to be as quick as possible.

Cheers,
Ben.
Avatar of Alfredo Luis Torres Serrano
Alfredo Luis Torres Serrano
Flag of United States of America image

ASKER CERTIFIED SOLUTION
Avatar of dwkor
dwkor
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
MlandaT,

Only overhead this CTE introduces is distinct sort on union operation. It's subject to test but I'm 99.9% sure that SQL Server would not choose NCI index intersection if you use regular query with OR.

In any case, it's a mood point. Both of us are incorrect with our advices. We overlooked # of records that author expect query to return. With the query returned 5% (20,000 out of 400,000 rows) or 100% at the future, the most optimal plan is clustered index scan.

Speaking of execution time - it looks like that most part of the time author is waiting for result set to be delivered rather than on other factors.
@dwkor... you are right. Both methods should work quite well - with more significant time spent delivering results.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of AJS_Developer
AJS_Developer

ASKER

Hi Everyone,

Thanks for all your responses!

I think your final conclusions are probably correct. The table in question is quite key, and my concern was that as the table grew, general application performance would suffer. If the best way to remedy this is to recommend clearing up any network contraints, then that is certainly not a problem.

The best advice from this was to create two separate indexes on both fields. I'm not implementing CTE, as i'm not seeing any difference in performance, but that may be due to the lower volume of records at the moment.

Thanks for all your help!!

Cheers,
Ben