On 23 Dec 2011, at 18:48, Wade Shearer wrote: >> I think you're thinking about this backwards. You're thinking of it as used >> in a programming language, when you're evaluating a single value. That is >> not the case here. MySQL is evaluating all of the rows, and deciding which >> ones match. In evaluating a single row, it would make sense for it to only >> evaluate the left side. However, database optimization generally comes from >> using indexes, not from optimizing the database server's look at a single >> row. In other words, the real optimization comes from limiting the number >> of rows looked at rather than limiting what is done evaluating each row. >> The latter is straightforward. The former is much harder. >> >> If your query contains "WHERE (A) OR (B)", and (A) can be optimized with an >> index, how does that help? You still need to evaluate every other row to >> determine if (B) is true. It'd actually be slower to use the index than to >> avoid it. >> >> Now, if (A) and (B) both use an index, then an index merge is possible. >> Most versions of MySQL do not support that very well. I know that Monty has >> done some work to make index merges work well in MariaDB, at least in 5.3. >> > That's what I was missing (I'm tired and sick :( ). I think you're right, > Steve. Thanks. >
Steve is correct, I just tested it on one of my own databases. _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
