We use Entity Frameworks for DB access and when we \"think\" LIKE statement - it actually generates CHARINDEX stuff. So, here is 2 simple queries, after I simplified them to
First, as you can see both queries are identical and neither can use index. CHARINDEX and LIKE perform same with wildcard. Ex: %YourValue%. However, there performance varies when you use wildcard like 'YourValue%'. Here, LIKE operator will likely to perform faster than CHARINDEX because it may allow partial scan of the index. Now, in your case, both queries are same but there performance is difference because of following possible reason:
Statistics: SQL Server maintains statistics for sub string in string columns which are use by LIKE operator but not fully usable for CHARINDEX. In that case, LIKE operator will work faster than CHARINDEX. You can force SQL Server to use index for CHARINDEX with proper table hints
Ex: FROM LOCAddress WITH (INDEX (index_name))
Read more Here, which in section "string summary stastics" says:
SQL Server 2008 includes patented technology for estimating the selectivity of LIKE conditions. It builds a statistical summary of substring frequency distribution for character columns (a string summary). This includes columns of type text, ntext, char, varchar, and nvarchar. Using the string summary, SQL Server can accurately estimate the selectivity of LIKE conditions where the pattern may have any number of wildcards in any combination.