Home/ Questions/Q 42783
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T15:23:31+00:00

I have a query that originally looks like this: select c.Id, c.Name, c.CountryCode, c.CustomerNumber,

  • 0

I have a query that originally looks like this:

select c.Id, c.Name, c.CountryCode, c.CustomerNumber, cacc.AccountNumber, ca.Line1, ca.CityName, ca.PostalCode from dbo.Customer as c left join dbo.CustomerAddress as ca on ca.CustomerId = c.Id left join dbo.CustomerAccount as cacc on cacc.CustomerId = c.Id where  c.CountryCode = 'XX' and (cacc.AccountNumber like '%C17%' or c.Name like '%op%'        or ca.Line1 like '%ae%' or ca.CityName like '%ab%' or ca.PostalCode like '%10%')

On a database with 90,000 records this query takes around 7 seconds to execute (obviously all the joins and likes are taxing).

I have been trying to find a way to bring the query execution time down with full-text search on the columns concerned. However, I haven’t seen an example of a full-text search that has three table joins like this, especially since my join condition is not part of the search term.

Is there a way to do this in full-text search?

@David

Yep, there are indexes on the Ids.

I’ve tried adding indexes on the CustomerAddress stuff (CityName, PostalCode, etc.) and it brought down the query to 3 seconds, but I still find that too slow for something like this.

Note that all of the text fields (with the exception of the ids) are nvarchars, and Line1 is an nvarchar 1000, so that might affect the speed, but still.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Run it through the query analyzer and see what the query plan is. My guess would be that the double root (ie. %ae%) searches are causing it do do a table scan when looking for the matching rows. Double root searches are inherently slow, as you can’t use any kind of index to match them usually.

    • 0