Query: further optimize translation of StartsWith

Currently we translate foobar.StartsWith(foo) into:

(foobar like foo +'%' and left(foobar, len(foo)) = foo) or foo = '' -- last term is removed if foo is non-null constant

however @rmacfadyen pointed out that for some scenarios the last term actually makes the query non-sargable.

If the term is removed completely, we return (arguably) incorrect data for case: null.StartsWith(“”).

We could however use the following translation:

(foobar like foo +'%' and left(foobar, len(foo)) = foo) or (foo = '' and foobar is null)

(and if we know that foobar can’t be null we could drop the term as well.

We need to do some more investigation on which scenarios are getting better with this translation (i.e. if its worth complicating the sql)

[darcythomas]

My observation/ 2 cents:

For me: [Foo] LIKE @foo + '%' AND (LEFT([Foo], LEN(@foo)) = @foo)) OR (@foo = '') is 100X slower than [Foo] LIKE @foo + '%'

This seems to be because the the query needs to perform a index scan rather than an index seek on IX_TableName_Foo

[glen-84]

It’s not even using LIKE for MySQL:

 WHERE (@__val_0 = '') OR (LEFT(`u`.`username`, CHAR_LENGTH(@__val_0)) = @__val_0))

Why is it doing this? I don’t think that this can use an index. This is such a simple case (startsWith).