MySQL查询非常慢

Question

This query takes a ridiculously long time to execute. Duration / Fetch: 89.778 sec / 0.000 sec

Here's the query:

SELECT tblcompanyoperat.COPSCountry,
       AVG(tbldshipfees.Dship Total AnnualUSD) / 
                              AVG(tblcopsyearonyear.COPSMinWageUSD) AS Expr1
FROM (SELECT tblcopsyearonyear.Company NAME,
          tblcopsyearonyear.COPSCountry,
          MAX(tblcopsyearonyear.COPSFinYearEnd) AS MaxOfCOPSFinYearEnd
      FROM tblcopsyearonyear
      GROUP BY tblcopsyearonyear.Company NAME,
        tblcopsyearonyear.COPSCountry
      ORDER BY tblcopsyearonyear.COPSCountry,
        MAX(tblcopsyearonyear.COPSFinYearEnd)) AS qryCOPSLatestInfoYr,
     ((tblcompany 
       INNER JOIN tblcompanyoperat 
       ON tblcompany.CompName = tblcompanyoperat.Company NAME) 
      INNER JOIN tblcopsyearonyear 
      ON tblcompanyoperat.COMPOPID = tblcopsyearonyear.COMPOPID)
INNER JOIN (tbldirectorships 
            INNER JOIN tbldshipfees 
            ON tbldirectorships.DIRECTORSHIPSID = bldshipfees.DSHIPID) 
ON tblcompany.CompName = tbldirectorships.DSHIPCOMPANYLINK
WHERE blcompany.CompSector = 'Retail'
GROUP BY tblcompany.CompSector, 
         blcompanyoperat.COPSCountry,
         tbldshipfees.DSHIP Position
HAVING (AVG(tblcopsyearonyear.COPSMinWageUSD) IS NOT NULL
        AND tbldshipfees.DSHIP Position LIKE 'Chief%')
ORDER BY MAX(qryCOPSLatestInfoYr.MaxOfCOPSFinYearEnd);

What optimizations, apart from indexing, can I use to speed things up? Explain extended output:

id selet_type   table                 type possible_keys                                          key                         key_len  ref                                       rows filtered Extra
1, PRIMARY,     tblcompany,           ref, PRIMARY,tblSECTORStblCOMPANY,                          tblSECTORStblCOMPANY,       768,     const,                                    7,   100.00,  Using where; Using index; Using temporary; Using filesort
1, PRIMARY,     tblcompanyoperat,     ref, PRIMARY,CompanyName,                                   CompanyName,                768,     lrsmnc.tblcompany.CompName,               3,   100.00,  Using where
1, PRIMARY,     tblcopsyearonyear,    ref, PRIMARY,COMPOPID,                                      COMPOPID,                   4,       lrsmnc.tblcompanyoperat.COMPOPID,         1,   100.00, 
1, PRIMARY,     tbldirectorships,     ref, PRIMARY,DIRECTORSHIPSID,tblCOMPANYtblDIRECTORSHIPS,    tblCOMPANYtblDIRECTORSHIPS, 768,     lrsmnc.tblcompanyoperat.Company Name,     12,  100.00,  Using where; Using index
1, PRIMARY,     tbldshipfees,         ref, DSHIPID,tbldshipfeesDSHIPID,                           DSHIPID,                    4,       lrsmnc.tbldirectorships.DIRECTORSHIPSID,  1,   100.00, 
1, PRIMARY,     <derived2>,           ALL,                                                                                                                                       310, 100.00,  Using join buffer
2, DERIVED,     tblcopsyearonyear,    ALL,                                                                                                                                       523, 100.00,  Using temporary; Using filesort

Answer 1

Moving tbldshipfees.DSHIP Position LIKE 'Chief%' from the HAVING clause to the WHERE clause will improve execution time. This is for two reasons.

First, no optimizations are done to items appearing in the HAVING clause for MySQL. This means that items may not be excluded using the index (as indicated in the EXPLAIN plan above.

Second, since the HAVING clause is applied immediately before returning the data to the client. As a result, time is spent unnecessarily in all of the operations (aggregate functions, ORDER BYs, etc) before they are removed, increasing the amount of time taken to process.

Reference: http://dev.mysql.com/doc/refman/5.5/en/select.html

Additionally, for future maintenance reasons, changing from implicit joins to explicit joins would be recommended, as per X-Zero's comments. This could have additional performance benefits, as it reduces the optimization required by the database server.