2017-04-14 12 views
2

此查詢以慢查詢日誌結束,因爲沒有索引的連接。我要添加哪個索引以及在哪裏?這個簡單的查詢需要從500ms到1,2s。我想它應該在100ms內輕鬆完成。要添加哪個索引?

SELECT users.*, user_roles.apirequests, user_roles.downloadrequests, NOW() AS now 
      FROM users 
      INNER JOIN user_roles ON user_roles.id = users.role 
      WHERE users.rsstoken = 
      '775e155c780ed5af9119f797f814c714' LIMIT 1; 

查看查詢和展示創建表:https://kopy.io/iCz1z

+1

您應該閱讀關於MySQL提供的'explain'功能。檢查文檔。它告訴你,它試圖使用現有的索引以及缺少的東西。 – arkascha

+0

你在rsstoken列上有'COLLATE utf8_unicode_ci'的任何原因? – thebjorn

+0

不知道。我沒有創建這個表格。這是一個API密鑰列。 – Bento

回答

2

對於此查詢:

SELECT u.*, ur.apirequests, ur.downloadrequests, NOW() AS now 
FROM users u INNER JOIN 
    user_roles ur 
    ON ur.id = u.role 
WHERE u.rsstoken = '775e155c780ed5af9119f797f814c714'; 

最好的指標是users(rsstoken, role)user_roles(id)。您已經擁有第二個索引,因爲id被聲明爲主鍵。

您還可以在user_roles的索引中包含apirequestsdownloadrequestsuser_roles(id, apirequests, downloadrequests)。這可能是一個非常小的優化 - 我通常會反對它,因爲id已經是主鍵並且行大小很小。

+0

當apirequests和downloadrequests不用於比較時,它們如何提供幫助? – thebjorn

+0

@thebjorn。 。 。這使索引成爲查詢的覆蓋索引。在這種情況下,幾乎沒有增益,因爲第一個鍵是表的主鍵。唯一的優點是索引小於原始表,因此可能會帶來很小的I/O優勢。在其他情況下,覆蓋索引可能非常有益。 –

+0

啊..這很酷:-) – thebjorn