Can MySQL use multiple indexes for a single query?

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.