May 31, 2005 at 9:43 am
Which is faster CHARINDEX or LIKE ?????
where fld_description is nvarchar(500)
where fld_description like '%HOLD%'
or
where charindex('hold',fld_description) > 0
May 31, 2005 at 9:56 am
Should be the same speed... with the wildcard at the front of the like, a scan is required to find all possible matches. Using charindex will always result in a scan. However if you where to do like 'abc%', this could result in an index seek. Again however, if you were to do something like this in a proc you'd get a scan again :
where somecol like @SomeParam + '%'
This is because the optimizer must take into consideration that the parameter could containt a wildcard at the beginning of the string.
May 31, 2005 at 10:28 am
thanks.. thats what i thought but wasnt sure..
June 1, 2005 at 4:19 am
Just an answer to Rémi's comment:
SQLserver will still use the index if you have this kind of query:
declare @v-2 varchar(50)
set @v-2 = 'E'
select * from dbo.T_CUS_customer
where cus_code_char like @v-2 + '%'
StmtText
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|--Bookmark Lookup(BOOKMARK[Bmk1000]), OBJECT
[LHC].[dbo].[T_CUS_customer]))
|--Nested Loops(Inner Join, OUTER REFERENCES[Expr1009], [Expr1010], LikeRangeInfo([@v]+'%', NULL)))
|--Compute Scalar(DEFINE[Expr1009]=Convert(LikeRangeStart([@v]+'%', NULL)), [Expr1010]=Convert(LikeRangeEnd([@v]+'%', NULL)), [Expr1007]=LikeRangeInfo([@v]+'%', NULL)))
| |--Constant Scan
|--Index Seek(OBJECT[LHC].[dbo].[T_CUS_customer].[IX_1_CUS_code_char]), SEEK
[T_CUS_customer].[cus_code_char] > [Expr1009] AND [T_CUS_customer].[cus_code_char] < [Expr1010]), WHERE
like([T_CUS_customer].[cus_code_char], [@v]+'%', NULL)) ORDERED FORWARD)
and if you are using a clustered index you can even avoid the bookmark lookup:
declare @v-2 varchar(50)
set @v-2 = 'E'
select * from dbo.T_CUS_customer
where cus_name like @v-2 + '%'
StmtText
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|--Nested Loops(Inner Join, OUTER REFERENCES[Expr1009], [Expr1010], LikeRangeInfo([@v]+'%', NULL)))
|--Compute Scalar(DEFINE[Expr1009]=Convert(LikeRangeStart([@v]+'%', NULL)), [Expr1010]=Convert(LikeRangeEnd([@v]+'%', NULL)), [Expr1007]=LikeRangeInfo([@v]+'%', NULL)))
| |--Constant Scan
|--Clustered Index Seek(OBJECT[LHC].[dbo].[T_CUS_customer].[I_C_CUS]), SEEK
[T_CUS_customer].[cus_name] > [Expr1009] AND [T_CUS_customer].[cus_name] < [Expr1010]), WHERE
like([T_CUS_customer].[cus_name], [@v]+'%', NULL)) ORDERED FORWARD)
Bye
Gabor
June 1, 2005 at 7:24 am
I can't replicate that index seek here..
Can you post the ddl and some sample data so I can understand what I'm doing wrong?
June 1, 2005 at 7:54 am
Watch Gabor's code
declare @v-2 varchar(50)
set @v-2 = 'E'
select * from dbo.T_CUS_customer
where cus_code_char like @v-2 + '%'
There is no wildcard at the beginning, only at the end. So, if there is an index on that cus_code_char column, it's likely to be used.
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
June 1, 2005 at 7:56 am
I know that but this query results in a scan :
Declare @name as varchar(10)
set @Name = 'id'
Select * from dbo.SysColumns where name like @Name + '%'
June 1, 2005 at 8:05 am
There isn't a separate index on name. This column is at second position in another nonclustered indexes. So, I would say, this is somewhat expected behaviour.
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
June 1, 2005 at 8:11 am
That clears it up... obviously works now on another table.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply
This website stores cookies on your computer.
These cookies are used to improve your website experience and provide more personalized services to you, both on this website and through other media.
To find out more about the cookies we use, see our Privacy Policy