The problems are as follows. However, there may not be solutions.
* gs.gc=19 AND g.gl=6 -- filtering on two different tables. It will filter on one, then reach into the other table repeatedly ("Nested Loop Join").
* LEFT JOIN -- generally prevents starting with the table(s) after it. If you don't need "LEFT", get rid of it. Suggest you also do
EXPLAIN EXTENDED SELECT ...;
SHOW WARNINGS;
That will tell you what transformations the optimizer decided it could do.
* NULLs -- It would be nice to see SHOW CREATE TABLE. When key_len is "5" is strongly suspect that you are JOINing on a NULLable INT. Any columns that don't need to be NULL should be declared NOT NULL.
* "Rows" -- 13*1*10*5*1*10 = 6500 rows touched. (No that is not exact, for many reasons.) But it points out that a lot of rows are hit.
* "ref" -- good.
* "Using index" shows up only once -- I suspect there is more opportunity for such. (Need SHOW CREATE TABLE)
* Cache -- Are you using MyISAM? or InnoDB? (Did I already ask for SHOW CREATE TABLE?) See this for tuning the cache size:
http://mysql.rjweb.org/doc.php/memory
* Over-normalization -- the WHERE and ON clauses smell like normalization. Sometimes people do more normalization than is desirable for performance. (Hmmm... the CREATE TABLEs would make this somewhat obvious.)
* GROUP BY g.gc ORDER BY g.gd -- The GROUP BY needs one sort (unless it is optimized away); the ORDER BY needs a second sort. (Not solvable, just a note of where some of the performance loss is.
* TEXT fields? Perhaps temp tables had to hit disk. Use rationally-sized VARCHARs instead, where practical.
Akiban can handle things like gs.gc=19 AND g.gl=6.