LIKE运算符的预准备语句的执行计划

Question

I was wondering if there might be a difference between the execution plan created for a prepared query whether the '%' in a LIKE predicate is provided initially or later. What I mean whether this

SELECT * FROM table WHERE column LIKE ? || '%'

and then setting the placeholder to the value you are looking for or doing

SELECT * FROM table WHERE column LIKE ?

and then setting the placeholder to the value you're looking for plus the '%' suffix will result in different execution plans (with the assumption that first one will be more efficient).

In the first version, theoretically the database would know that what I'll likely be querying for is a prefix, and hence choose an index to do this, whereas for the second form, it is arbitrary and it cannot assume anything (that said, of course also with the first form I'm still free to put any % in there, so there would still be some fallback needed).

So might there be some performance benefit, especially on some heavily optimized commercial DBs, of doing the first one or will it not matter as both execution plans will be the same and need to do some extra preparation once the parameter is filled in?

Answer 1

You do not specify the database, but the use of double vertical parts for string concatenation suggests Oracle or Postgres.

In any case, most database engines are smart enough to recognize this:

where col like 'pattern%'

as something that can be handled by an index on col . I'm pretty sure both Postgres and Oracle do this optimization (as do MySQL and SQL Server and probably other databases).

The next part is speculation. I would imagine that when substituting a parameterized constant into the string, the same optimization works. You can check this by looking at the execution plans for such queries in your database.

If you need more sophisticated text matching algorithms, most databases have support for full text search -- and this can considerably speed such searching operations.

Answer 2

A prepared statement which actually leads to a cached plan will never use any index for this, because it's not know what kind of wildcards are within the supplied parameter. Only if the optimizer decides not to use a cached plan (ie re-optimizes the query every time based on the actual value in the parameter) it might actually to use an index.