SQL Server Forums
Profile | Register | Active Topics | Members | Search | Forum FAQ
 
Register Now and get your question answered!
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 SQL Server 2008 Forums
 Transact-SQL (2008)
 LIKE clause perf and efficiency
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

tech_1
Posting Yak Master

105 Posts

Posted - 02/11/2013 :  12:19:41  Show Profile  Reply with Quote
Hi all.
I think I discovered something that will save me a bunch of time when convert dynamic SQL to a SPROC.

now, the old code basically inserts a LIKE clause if it finds a wildchar. If not, then it uses a different path to construct the where clause statement.

Experimenting, I tried using a LIKE clause without having the '%' char in my parameter and it seems to work like an '=' clause.
This means that I only need to do a single branch irrespective if a % char is entered in the param or not.

for example:

quote:

DECLARE @name varchar(10)
SET @name = 'john'

SELECT * FROM Person WHERE FullName LIKE @name



this would bring up 0 results because there could be no fullname entries with just "John" but if I did:

quote:

DECLARE @name varchar(10)
SET @name = 'john%'

SELECT * FROM Person WHERE FullName LIKE @name



it could bring a whole list of names that begin with "John".

Same could be applied for say reference numbers/ordernumbers where you could enter an exact match, the LIKE clause would bring it (without the wildchar) or if you added a wildchar it would bring a list of them matching the criteria.

my question is: how good/bad is it for me to just use the LIKE clause everywhere? What are the perf implications?

James K
Flowing Fount of Yak Knowledge

3578 Posts

Posted - 02/11/2013 :  12:30:10  Show Profile  Reply with Quote
quote:
my question is: how good/bad is it for me to just use the LIKE clause everywhere? What are the perf implications?
I don't think there is any performance hit at all.

I recall reading one of your earlier posts related to this, and meant to post a reply to it - but got dragged away into something else by my wife or my boss (No, they are not the same person although one pretends to be both sometimes ;). What I meant to say was that when you parameterize the query and make it into a stored procedure, you are likely to run into the so called "parameter-sniffing" problem. That happens when SQL Server reuses a query plan that was optimized for one set of parameters for another set of parameters and the existing query plan for this second set of parameters turns out to be very inefficient.

These are sometimes called "catch-all" queries. Ways to address this problem using dynamic SQL in a manner that is not susceptible to SQL injection is described here: http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries/

Editing: One thing I failed to mention is that there is a logical difference between LIKE and = when there are trailing spaces. This example shows:
CREATE TABLE #tmp(x VARCHAR(32));
INSERT INTO #tmp VALUES ('John'),('John   ');
SELECT * FROM #tmp WHERE x LIKE 'John   '
SELECT * FROM #tmp WHERE x = 'John   '
DROP TABLE #tmp;

Edited by - James K on 02/11/2013 12:35:42
Go to Top of Page

tech_1
Posting Yak Master

105 Posts

Posted - 02/11/2013 :  14:13:33  Show Profile  Reply with Quote
thanks, I appreciate that James K.
The trailing of spaces etc.. is not a problem in the context/area I am working with because everything will be trimmed from the top down (down to the SQL end)

I was thinking about doing the dynamic SQL in the SPROC but want to stay away from that for a number of reasons (performance, and also debugging would be a pain!)
I guess I have to stick with the "do every single combination possible" type of SPROC.
Go to Top of Page

visakh16
Very Important crosS Applying yaK Herder

India
52317 Posts

Posted - 02/11/2013 :  23:05:40  Show Profile  Reply with Quote
quote:
Originally posted by tech_1

thanks, I appreciate that James K.
The trailing of spaces etc.. is not a problem in the context/area I am working with because everything will be trimmed from the top down (down to the SQL end)

I was thinking about doing the dynamic SQL in the SPROC but want to stay away from that for a number of reasons (performance, and also debugging would be a pain!)
I guess I have to stick with the "do every single combination possible" type of SPROC.


debugging will not be an issue so far as you've intermediate print statements to print out concatenated query. What we usually do in procedures where we use dynamic sql is to create an additional parameter called @Debug of bit type with default 0. Inside code we add statements to print intermediate queries by giving an IF condition like

IF @Debug=1
PRINT @SQL

WHile debugging we will set bit as 1 which will display the intermediate queries it creates on the fly. Copy and paste this onto new query window in SSMS and you'll be able to compile and execute it to see if query created is correct.

------------------------------------------------------------------------------------------------------
SQL Server MVP
http://visakhm.blogspot.com/

Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
SQL Server Forums © 2000-2009 SQLTeam Publishing, LLC Go To Top Of Page
This page was generated in 0.06 seconds. Powered By: Snitz Forums 2000