應該索引哪些內容以提高性能？

鑑於此查詢，應對哪個或哪些列進行索引以優化查詢性能？應該索引哪些內容以提高性能？

SELECT * 
    FROM `activities` 
WHERE (user_id = 90000 AND activity_type_id IN(300,400,808,9494)) 
ORDER BY created_at DESC 
LIMIT 70

來源

2011-05-29 keruilin

你能提供關於模式的更多信息嗎？例如，user_id是一個主鍵（因此已經有一個唯一的索引）？ – Cole 2011-05-29 00:53:41

@Cole：'user_id'不太可能是'activities'表中的（唯一）主鍵列。它可能（可能是）主鍵的一部分。 – 2011-05-29 00:59:03

@Jonathan謝謝，我剛剛意識到我從未考慮過將複合鍵添加到我自己的表中。我必須記住這些。 – Cole 2011-05-30 04:27:24

通常，選擇過濾器可以使用user_id或activity_type_id或兩者（以任一順序）的索引。

訂購操作可能能夠在created_at上使用過濾器。

對於這個查詢，(user_id, activity_type_id)上的複合索引很可能會給出最好的結果，假設MySQL實際上可以使用它。如果不這樣做，指數user_id可能會比activity_type_id好，因爲它可能會提供更好的選擇性。其中一個原因是，如果索引是activity_type_id，那麼索引將有4個子部分進行掃描，而如果僅使用user_id上的索引，則只有一個子部分進行掃描。

試圖依賴索引排序順序很可能意味着全表掃描，因此它不太可能是有益的。我不會在created_at上創建索引來支持此查詢;可能會有其他疑問，這將是有益的。

來源

2011-05-29 00:56:26

當然，WHERE子句中的所有列都應該被索引。

但IN子句可能需要表掃描。

我想讀這些答案可能幫助：

MySQL not using indexes with WHERE IN clause?

來源

2011-05-29 00:53:12 duffymo

你正在做的USER_ID和activity_type_id查找，所以創建兩列索引。

來源

2011-05-29 00:53:33

我會指標只是user_id ..

來源

2011-05-29 00:53:35

假設你沒有隱瞞實際生產代碼JOIN，索引「activity_type_id」應該是最好的一個。

來源

2011-05-29 00:54:42

我會在活動表上添加兩個索引，一個放在（user_id，activity_type_id）和另一個放在（created_dt）上。我也很想看看「活動」表中的哪些字段實際使用了;如果您可以減少檢索的字段數量，則可以縮短響應時間。我還會在之前對進行查詢計劃，並對數據庫進行任何更改，然後將其與生成的計劃進行比較，進行任何/所有更改。

分享和享受。

來源

2011-05-29 03:22:23

我wouldnt創建任何額外的索引，而不是我會設計我的表，因此它充分利用innodb集羣主鍵！

create table activities 
(
user_id int unsigned not null, 
activity_id smallint unsigned not null, 
primary key (user_id, activity_id) -- composite clustered primary key order is important 
) 
engine=innodb;

或

create table activities 
(
user_id int unsigned not null, 
activity_id smallint unsigned not null, 
primary key (activity_id, user_id) -- hmmmm the other way round, why is that ? 
) 
engine=innodb;

而且，具有以下的讀出：

MySQL and NoSQL: Help me to choose the right one

How to avoid "Using temporary" in many-to-many queries?

60 million entries, select entries from a certain month. How to optimize database?

Rewriting mysql select to reduce time and writing tmp to disk

希望它可以幫助和FTW記住InnoDB的;）

來源

2011-05-29 03:49:26

爲了讓你必須考慮到以下正確的決定：

如果user_id是主鍵的一部分（你說它可能是），那麼表的聚集索引的主鍵？如果是這樣，user_id是否在聚簇索引的第一個位置？如果是這樣，那麼您希望每個用戶有多少活動？如果每個用戶有1-40個活動，那麼添加另一個索引將不會有用，並且會影響插入性能。原因在於用戶的所有活動行都會聚集在一起，並可能位於同一數據庫頁面上，因此將activity_type_id添加到索引將無濟於事。

如果主鍵未被聚集，並且user_id不在主鍵的第一個位置，或者user_id不在主鍵中，那麼最好的方法是使用user_id的非聚集索引， activity_type_id。查詢優化器應該足夠聰明以使用索引，因爲即使存在IN子句，user_id和activity_type_id也位於where語句中。您也可以在索引的末尾添加created_at，因爲您以這種方式訂購查詢結果。

請注意專門爲一個查詢創建索引，但如果查詢大量使用，通常是必要的。

來源

2011-05-30 01:41:27 user747900

應該索引哪些內容以提高性能？

回答

相關問題