Performance on searching a name field with the like clause

Question

Hi.  We run 2012 std and I suspect we'll be running into challenges as my user has expressed an interest in searching data based on a like clause across a contact name column that is varchar(80).  The like clause is shown below.  The
question is whether or not an index on this column will (if we make one) even be used when a like clause is introduced?  And any other advice the community may offer.  I'll ask my user if they could limit the search to patterns that match starting
in position 1 but suspect they'll say no.  Currently the table has 1.5 million rows , one pk, and is approx 1100 bytes wide if varchars are fully used.
where ltrim(rtrim(e.[ContactName])) like '%' +IsNull(@contactName1,'') + '%'

Answer 1

Hi.  We run 2012 std and I suspect we'll be running into challenges as my user has expressed an interest in searching data based on a like clause across a contact name column that is varchar(80).  The like clause is shown below.  The
question is whether or not an index on this column will (if we make one) even be used when a like clause is introduced?  And any other advice the community may offer.  I'll ask my user if they could limit the search to patterns that match starting
in position 1 but suspect they'll say no.  Currently the table has 1.5 million rows , one pk, and is approx 1100 bytes wide if varchars are fully used.
where ltrim(rtrim(e.[ContactName])) like '%' +IsNull(@contactName1,'') + '%'
Hi db042190,
>> The question is whether or not an index on this column will (if we make one) even be used when a like clause is introduced?
A simple index use an exact value in order to compare it (it orer the tree according to the value). For most cases it will not be a good solution for filtering by "like" (in some cases it can help you use "index scan", but it will not
be able to use "index seek"). There are several options that can help in this issue dapending on your interface and the way you use the data:
(1) Full Text Index as Olaf mentioned
(2) Another option, which is very useful in some cases, based on using an external table, which store list of searching words (if the user try a new search then you can scan the original table, which this is one-time-job for each new word). This is actually
work on the same idea of using FTS, but it is more flexible and give you direct control if you need to use word searching and not phrase/free-text searching. This table is indexed and the search is done on this table, and not the original table. Those two
tables have relations many-to-many, and you use a simple JOIN to get the results 
>> limit the search to patterns
This can be a game changer!
There is a simple solution that might help you in this case which is very useful! you can create a computed column that store the value according to your patterns, and then create index on that
column. For example if the your pattern is filter by "starting with 10 specific char" then you can use simple LEFT function like in this code:
CREATE TABLE t (LongText nvarchar(MAX), MyPatSearch as convert(nvarchar(10),LEFT(LongText,10)));
GO
CREATE NONCLUSTERED INDEX IX_MyPatSearch ON t (MyPatSearch);
GO
* using computed column with string like in this example, you have to use CONVERT since Data type is requirements for index computed column.
  Ronen Ariely
 [Personal Site]    [Blog]    [Facebook]