問題描述：
某條sql語句在測試環境執行只需要1秒不到，到了生產環境執行需要8秒以上
在phpmyadmin里面執行性能分析，發現sending data占用了差不多90%以上的時間
查詢一下“Sending data”狀態的含義，原來這個狀態的名稱很具有誤導性，所謂的“Sending data”並不是單純的發送數據，而是包括“收集 + 發送 數據”。
這里的關鍵是為什么要收集數據，原因在於：mysql使用“索引”完成查詢結束后，mysql得到了一堆的行id，如果有的列並不在索引中，mysql需要重新到“數據行”上將需要返回的數據讀取出來返回個客戶端。
猜測可能是索引沒有添加正確，於是采用
explain分析方法，在查詢語句前添加expain，如下可以在phpadmin里面執行，也可以在navicat中執行：
explain SELECT
a.media_id,
a.user_id,
a.media_type,
a.title,
a.media_url,
a.description,
a.cover_url,
a.like_count,
a.play_count,
a.reply_count,
a.relay_count,
a.share_count,
a.length,
a.width,
a.length_time,
a.STATUS,
a.verification,
a.encapsulate_status,
a.create_time,
a.update_time,
a.audit_time,
CASE WHEN c.id IS NOT NULL THEN 1 ELSE 0 END niuren,
c.coefficient,
CASE WHEN d.id IS NOT NULL THEN 1 ELSE 0 END remen,
d.coefficient coefficientReMen,
b.nickname,
p.official,
p.theme_id,
p.theme_name,
u.size
FROM
tbl_media_info a
LEFT JOIN tbl_user_info b ON a.user_id=b.user_id
LEFT JOIN tbl_ranking_config c ON c.media_id=a.media_id AND c.type=3
LEFT JOIN tbl_ranking_config d ON d.media_id=a.media_id AND d.type=2
LEFT JOIN tbl_media_theme_config t ON a.media_id = t.media_id
LEFT JOIN tbl_theme_info p ON t.theme_id = p.theme_id
LEFT JOIN tbl_upload_status u ON u.url = a.media_url
GROUP BY a.media_id
order by a.create_time desc limit 0,20
通過explain查詢分析，可以看到結果中possible_keys為空，說明沒有用到索引
LEFT JOIN tbl_media_info t5 ON t1.user_id = t5.user_id，而這個關聯查詢用到了user_id，需要在這個字段上添加索引
添加索引，問題解決，查詢只需要0.5秒左右
