I’ve got one. I found this page because I was looking for an explanation for how my JOIN operation could get faster when I took out the WHERE clause even though that greatly multiplied the JOIN size.

Because the other side of the JOIN already limited the records as needed, the WHERE clause on the first subquery was unneeded. I assumed that having a smaller resultset would increase performance because less memory was copied and used; however, instead, having the WHERE clause on that one table tripled the overall runtime of the query. Upon reflection, I presume that’s because the first subquery requires the database engine to set up a temporary table to store the resultset, while a SELECT without a WHERE means that it can read directly from the source database (likely cached) when it creates the JOINed resultset.

So, this is interesting research; and I am keen enough to find out more that I’m going to do tests of my own.

Also explain gives half (???) the rows if using the index.

I can understand that the index takes less space than the table as all the keys are the same but why the optimizer believes that using the index requieres half the rows? because is a b-tree?

Pep

MySQL Optimizer does something called: Constant condition removal.
This means that a condition like this TRUE or 5=5 is going to be
removed by the optimizer prior to query execution.

Mark,
Is it possible that using a index is faster because counting index records is
faster than counting table records? It is important to realize that all the
index keys are the same so probably the table is larger than the index and
executing the query takes less io -> faster. (I’ll check table size vs. index size)

Pep

ie, can you compare with

WHERE TRUE
and
WHERE 1=1
and
WHERE ‘a’='a’? That would be much more interesting, because the 60% or 87% are likely because of the access and comparison costs. But how much is the actual WHERE costing?

There’s also explain plan overhead.