Really slow join, limit and order_by query
I see some issues: 


category_pointers is missing a unique key on its natural primary key.  Try using (category, isbn) as the primary key. It may be helpful to have the reverse index ('isbn', 'category'). This query can run strictly on the index. 
category_pointers has a surrogate key for its primary index.  I would drop it and use the natural key (category, isbn).   I see this pattern far too frequently.  A surrogate key on a join table is a code smell to me.
The books_popularity_index may work better as a compound index defined as (popularity, isbn).  In index on (isbn, popularity) may help some search strategies.
The books table has a valid natural key isbn and a surrogate key id.  I would drop the id column as the primary index and use isbn as the primary key.
Use of RIGHT JOIN rather than INNER JOIN overrides the choice of driving table.  However, you are missing indexes which may help the query run faster.


Items 1 and 3 may improve your query performance.  Items 2 and 4 may be related to possible fragmentation of index ordered database tables.  

I see two likely search paths:


small category: category - isbn - popularity.  This requires a sort on populary after all books in the category are found.  A (isbn, popularity) index might help.
large category: popularity - isbn - category.  Finds first thirty matching records without requiring a sort.  A large unpopular category may perform slowly. 


Running the query prefixed by EXPLAIN should tell you how the data is being searched for.  This may help understand why the query is slow.  In most cases, each of the tables should be accessed by an index.  Only the index on category_pointers should be required.  (This may require both indexes specified above.)