Is it possible to index a computed column used in ORDER BY?
There are several things you can do to improve the efficiency of the query.


First, index the tables. OK, it's not trivial to do this. And any indexing should be considered in relation with all the queries you are running in the database. Lets pretend that this is the only query or that it is the most crucial one.  


We'll break this task into the 2 tables involved. The first table, uploaded, appears - besides the join - only in the select list (all its columns) and in the 2 WHERE conditions:

AND uploaded.active = 1 
AND uploaded.nsfw = 0 


Two simple equality conditions, so the immediate thought is to make an index on these two columns or better include the joining column (this is a technicality, as the table is using the MyISAM engine): (active, nsfw, file_name)

ALTER TABLE uploaded
  ADD INDEX active_nsfw_fname_IX
    (active, nsfw, filename) ;

Then we go to the downloaded table. This is more complicated. Its columns do not appear in the select list (only an aggregate result, the count) but they are used in the WHERE, GROUP BY clauses and (the computed count) in the ORDER BY / LIMIT. To complicate matters, one of the conditions is a range condition (&gt;) and not equality:

WHERE downloaded.completed = 1
  AND downloaded.datetime &gt; DATE_SUB(NOW(), INTERVAL 7 DAY) 
GROUP BY downloaded.file_name 
ORDER BY downloaded_count DESC LIMIT 30 


If both were equalities, I'd blindly add an index on (completed, datetime, file_name) but in this case, I would first try an index on (completed, file_name, datetime), i.e. first the column from the equality check, then the column in the grouping and finally the other.

ALTER TABLE downloaded
  ADD INDEX comp_fname_dt_IX
    (completed, file_name, datetime) ;


Another improvement that is often possible in queries that have ORDER BY and LIMIT is to first do this in a derived table and then join the other tables. We can't really do this exactly here but we can try to put this in the derived table.
Notice that from the uploaded table only the columns in the active_nsfw_fname_IX index are used
And that for the downloaded table the columns of the comp_fname_dt_IX index are aligned with the order that queries are (logically) executed (WHERE - GROUP BY - SELECT):

( SELECT COUNT(CASE WHEN d.datetime &gt; DATE_SUB(NOW(), INTERVAL 7 DAY) THEN 1 END)
             AS downloaded_count
       , d.file_name
  FROM downloaded AS d JOIN uploaded AS u 
    ON d.file_name = u.file_name 
  WHERE d.completed = 1
    AND u.active = 1 
    AND u.nsfw = 0 
  GROUP BY d.file_name 
  ORDER BY downloaded_count DESC LIMIT 30
)



The query finally becomes:

SELECT dc.downloaded_count
     , dc.file_name                 -- you can remove this column from the results
     , up.*                         -- as uploaded has a file_name column
FROM 
    ( SELECT COUNT(CASE WHEN d.datetime &gt; DATE_SUB(NOW(), INTERVAL 7 DAY) THEN 1 END)
                 AS downloaded_count
           , d.file_name
      FROM downloaded AS d JOIN uploaded AS u 
        ON d.file_name = u.file_name 
      WHERE d.completed = 1
        AND u.active = 1 
        AND u.nsfw = 0 
      GROUP BY d.file_name 
      ORDER BY downloaded_count DESC LIMIT 30
    ) AS dc
    JOIN uploaded AS up
      ON dc.file_name = up.file_name 
ORDER BY downloaded_count DESC ;                 -- no need for LIMIT here


Testing time! I suggest you add these 2 indexes and then time the queries, both your original one and the one above.



And to answer your question, no it is not possible to index the aggregated column. MySQL has neither computed columns nor materialized views which is what is needed in this case (only MariaDB has implemented persistent, computed columns but that wouldn't help you in this query.)

So, the only way is to try by indexing and rewriting the query to reduce as much as possible the number of rows that will be ordered by - and that's what I essentially tried to accomplish above.

You will still see a "filesort" in the EXPLAIN but it's totally different (in terms of performance) to sort 100 than 10k rows.