Re: Subquery with range uses filesort

[Rick James]

> I'm not actually fetching that column.

SELECT * was your query. It _does_ fetch that column. If you are not actually using "SELECT *", then the EXPLAINs you provided may be bogus, plus much of this thread, may be irrelevant. MySQL does many optimizations. "*" prevents some of them. Please show the actual query.

> The temp table is declared "engine=memory".

There are two types of temp tables -- those that you create explicitly, and those that are implicitly created when it says "using temporary" or "using filesort". It is even possible that a single SELECT can involve more than one implicit temp table.

My discussion of BLOB and MEMORY/MyISAM was referring to the implicit temp table involved "filesort".

> I figured out that the temp table had switched from MyISAM to InnoDB.

New versions of MySQL default to InnoDB (previously MyISAM). You can (should?) always explicitly state the ENGINE when doing CREATE TABLE.

> The results can contain anywhere from one player to 54,106.

And what do you do if there are thousands of players in the output? Show them all? Paginate?

> With InnoDB, updating one row of the temp table took 0.1 second.

Implicit temp tables have no indexes (until ~5.6).
Explicit temp tables have indexes only if you specify them -- and it is often a good idea to do so.
I can't be sure, but perhaps it took as long as 0.1s because of not having a good index.

> I would think the sorting would take a noticeable amount of time.

Yes, sorting takes time. But it is rarely the main cause of slow queries. It can, however, be heavily implicated. Example:
SELECT ... ORDER BY foo LIMIT 10
If it cannot use an index, it will gather _all_ the rows, sort them, and only then count to 10.
If it can use an index, it may be able to read only the 10 desired rows, not touching the rest of the rows.