How to improve query with multiple LIKEs with leading wildcards

  • I have an app that I'm adding a generic search function to. The user types in a word, or phrase, or portion of a word, and all items matching this search string anywhere in the database is returned. No surprise, it's running like a dog. Indexes may help, but not for the leading wildcards. Here's the WHERE clause:

    WHERE @SearchTerm = A.EmpLogin

    OR @SearchTerm = CM.EmpLogin

    OR @SearchTerm = EC.ClientNum

    OR EC.ClientName LIKE '%' + @SearchTerm + '%'

    OR @SearchTerm = EM.MatterName

    OR @SearchTerm = EM.MatterDesc

    OR ET.[From] LIKE '%' + @SearchTerm + '%'

    OR ET.[To] LIKE '%' + @SearchTerm + '%'

    OR ET.CC LIKE '%' + @SearchTerm + '%'

    OR ET.BCC LIKE '%' + @SearchTerm + '%'

    OR ET.[Subject] LIKE '%' + @SearchTerm + '%'

    OR ET.MessageBody LIKE '%' + @SearchTerm + '%'

    OR @SearchTerm = E.EmpLogin

    OR E.FirstName LIKE @SearchTerm + '%'

    OR E.LastName LIKE @SearchTerm + '%'

    OR E.Title LIKE '%' + @SearchTerm + '%'

    OR @SearchTerm = LE.EmpLogin

    OR D.[Description] LIKE '%' + @SearchTerm + '%'

    OR @SearchTerm = D.ResAttorneyID

    OR D.Comments LIKE '%' + @SearchTerm + '%'

    I need the leading wildcards for fields like Comments and Description, basically anywhere you see wildcards they're needed. I have two questions: where would you recommend I put indexes (and of what type) and is there a better way to construct this query so that I can search for my search term within the text of fields, but it runs faster than it is now?

    As a side note, only a few very trusted employees will have access to the app that this is used in, so I don't think I need to use dynamic sql here.

    Thanks much!

  • Thanks! Can you suggest an app or two that would be appropriate?

  • I have an app that I'm adding a generic search function to. The user types in a word, or phrase, or portion of a word, and all items matching this search string anywhere in the database is returned. No surprise, it's running like a dog. Indexes may help, but not for the leading wildcards. Here's the WHERE clause:

    I would take a slightly different approach than Celko. Just don't do this at all. There is no such thing as a third party app that can return a value that it finds in any column or row in the database in anything resembling a reasonable amount of time. At the very least you need to make the user identify what to search. This type of catch all search will never be anything but horribly slow.

    You might want to read this article on Gail's blog about catch-all queries. I think you need to convert to something along the lines of what she explains. http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries/[/url]

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • Thank you. How about FULL TEXT searching? Microsoft says it's faster than the equivalent LIKE statements. I've never used it. Is it worth looking into in this case?

  • Melanie Peterson (12/4/2012)


    Thank you. How about FULL TEXT searching? Microsoft says it's faster than the equivalent LIKE statements. I've never used it. Is it worth looking into in this case?

    It would certainly have a lot of potential of improving what you are trying to do. It is pretty simple to implement. Try it out on a dev server and see if you can get it to do what you want.

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • Thanks again.

  • CELKO (12/4/2012)


    Would you try to cut wood with a screw driver?

    BWAAA-HAAA!!!! ONLY if I couldn't find my hammer! :-D:-P

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • 😀 Are law firms always so ridiculous? Never mind, I've worked at them since 1987, I know the answer. Email is only part of the data we need to trawl through, but not a bad guess! Thanks for the info.

  • CELKO (12/4/2012)


    Can you suggest an app or two that would be appropriate?

    ZyIndex was the Gold Standard for law offices in my day.

    Is anyone else wondering how long ago this might be? 😀

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • FYI, I tried implementing Full Text Indexing, but it had no effect on the time the query takes to return results. In some cases it takes longer. We also looked into using our Google Mini appliance (which we use for our Intranet searches), but only the grown-up Google appliance supports database searches without serious, serious agony. Since we're not going to spend $10,000 on something that only a few, albeit high-level, people are going to use, I think they're just going to have to wait around 15 seconds for their search results. And so it goes. Thank you for your suggestions, though! 🙂

  • I figured it out! Thanks to this link, I changed all the ORs to UNIONs. My query now runs in less than one second. :smooooth:

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply