Can MySQL use multiple indexes for a single query?

Imagine a table with multiple columns, say, id, a, b, c, d, e. I usually select by id, however, there are multiple queries in the client app that uses various conditions over subsets of the columns.

When MySQL executes a query on a single table with multiple WHERE conditions on multiple columns, can it really make use of indexes created on different columns? Or the only way to make it fast is to create multi-column indexes for all possible queries?

Yes, MySQL can use multiple index for a single query. The optimizer will determine which indexes will benefit the query. You can use EXPLAIN to obtain information about how MySQL executes a statement. You can add or ignore indexes using hints like so:

SELECT * FROM t1 USE INDEX (i1) IGNORE INDEX FOR ORDER BY (i2) ORDER BY a;

I would suggest reading up on how MySQL uses indexes.

Just a few excerpts:

> If there is a choice between multiple indexes, MySQL normally uses the > index that finds the smallest number of rows. > > If a multiple-column index exists on col1 and col2, the appropriate > rows can be fetched directly. If separate single-column indexes exist > on col1 and col2, the optimizer will attempt to use the Index Merge > optimization (see Section 8.2.1.4, “Index Merge Optimization”), or > attempt to find the most restrictive index by deciding which index > finds fewer rows and using that index to fetch the rows.

Classically, MySQL can use one index per table reference in a given query. However, in more recent versions of MySQL, an operation called an index merge can take place and allow MySQL to use more than one index per table.

http://openquery.com/blog/mysql-50-index-merge-using-multiple-indexes

Mysql can use index merge to merge the results of two indexes. But this is not really the preferred way of mysql. It will use two indexes if that optimizes the query execution. but this is also a hint for the query developer to create a composite index.

An index merge is by no means equivalent to a composite index. here is an excerpt from Baron Schwartz book -

> The index merge strategy sometimes works very well, but it’s more > common for it to actually be an indication of a poorly indexed table: > > • When the server intersects indexes (usually for AND conditions), it > usually means that you need a single index with all the relevant > columns, not multiple indexes that have to be combined.
> • When the server unions indexes (usually for OR conditions), sometimes the > algorithm’s buffering, sorting, and merging operations use lots of CPU > and memory resources. This is especially true if not all of the > indexes are very selective, so the scans return lots of rows to the > merge operation.

• Each SELECT in a query -- think UNION, subquery, derived table, etc -- is optimized separately. That is each might use different indexes.
• One SELECT can use multiple indexes in what it calls "index merge". This is rarely used.
• When the EXPLAIN says it is using Index merge (intersect), then it can almost always be improved by using a composite index containing the columns used by the intersected indexes.
• Index merge (union) is sometimes (rarely) used for an OR. Such can perhaps be improved by rewriting the query to be the UNION of two SELECTs.