Does SQLite 'merge' prefixes used by LIKE? - sqlite

Question

I have a query like
select * from tbl where name like 'a%' or name like 'abc%';
Does SQLite search 'a%' and 'abc%' separately? Would it check abc% is included by a%, and do only one search?
"explain query plan" returns
"0" "0" "0" "SEARCH TABLE traces USING PRIMARY KEY (name>? AND name<?)"
"0" "0" "0" "SEARCH TABLE traces USING PRIMARY KEY (name>? AND name<?)"
Is it what happens at run time?

Answer 1

Does SQLite search 'a%' and 'abc%' separately? Would it check abc% is
included by a%, and do only one search?
I think neither is the correct answer as it appears to be in-between the two options given.
I think trawling through the documenting will explain a little.
First port of call is The SQLite Query Optimizer Overview . This says :-
If the WHERE clause is composed of constraints separate by the OR
operator then the entire clause is considered to be a single "term" to
which the OR-clause optimization is applied.
Addiotnally in EXPLAIN QUERY PLAN it states :-
If the WHERE clause of a query contains an OR expression, then SQLite
might use the "OR by union" strategy (also described here).
link included below to 1.8. OR-Connected Terms In The WHERE Clause
In this
case there will be two SEARCH records, one for each index, with the
same values in both the "order" and "from" columns. For example:
sqlite> CREATE INDEX i3 ON t1(b);
sqlite> EXPLAIN QUERY PLAN SELECT * FROM t1 WHERE a=1 OR b=2;
0|0|0|SEARCH TABLE t1 USING COVERING INDEX i2 (a=?)
0|0|0|SEARCH TABLE t1 USING INDEX i3 (b=?)
So it very much appears that the "OR by union" strategy is being used as you have:-
"0" "0" "0" "SEARCH TABLE traces USING PRIMARY KEY (name>? AND name<?)"
"0" "0" "0" "SEARCH TABLE traces USING PRIMARY KEY (name>? AND name<?)"
Or-clause optimization, is explained here:-
3.0 OR optimizations (same as first document). However there are lots of mights, rather I think that link as provided in the EXPLAIN QUERY PLAN to 1.8. OR-Connected Terms In The WHERE Clause is more pertinent, this includes :-
1.8. OR-Connected Terms In The WHERE Clause
Multi-column indices only work if the constraint terms in the WHERE
clause of the query are connected by AND. So Idx3 and Idx4 are helpful
when the search is for items that are both Oranges and grown in
California, but neither index would be that useful if we wanted all
items that were either oranges or are grown in California.
SELECT price FROM FruitsForSale WHERE fruit='Orange' OR state='CA';
When confronted with OR-connected terms in a WHERE clause, SQLite
examines each OR term separately and tries to use an index to find the
rowids associated with each term. It then takes the union of the
resulting rowid sets to find the end result. The following figure
illustrates this process:
The diagram above implies that SQLite computes all of the rowids
first and then combines them with a union operation before starting to
do rowid lookups on the original table. In reality, the rowid lookups
are interspersed with rowid computations. SQLite uses one index at a
time to find rowids while remembering which rowids it has seen before
so as to avoid duplicates. That is just an implementation detail,
though. The diagram, while not 100% accurate, provides a good overview
of what is happening.
In order for the OR-by-UNION technique shown above to be useful, there
must be an index available that helps resolve every OR-connected term
in the WHERE clause. If even a single OR-connected term is not
indexed, then a full table scan would have to be done in order to find
the rowids generated by the one term, and if SQLite has to do a full
table scan, it might as well do it on the original table and get all
of the results in a single pass without having to mess with union
operations and follow-on binary searches.
One can see how the OR-by-UNION technique could also be leveraged to
use multiple indices on queries where the WHERE clause has terms
connected by AND, by using an intersect operator in place of union.
Many SQL database engines will do just that. But the performance gain
over using just a single index is slight and so SQLite does not
implement that technique at this time. However, a future version
SQLite might be enhanced to support AND-by-INTERSECT.
Another consideration is 4.0 The LIKE optimization. However, I believe this is on a per LIKE clause basis only.