對於按主鍵排序時的 Mysql ORDER BY LIMIT 查詢，我是否需要復合索引？

Question

如果我正在運行 MySQL ORDER BY LIMIT 查詢，其中 WHERE 子句在一列上進行過濾，而 ORDER BY 子句在主鍵列上進行過濾：

a) 我可以只在我正在執行 WHERE 的列上使用單個索引嗎？ 這里的例子是 index (team_id)

b) 還是最好同時在（WHERE 列，ORDER BY 列）上建立索引？ 這里的例子是 index (team_id, member_id)

我有一種預感，數據庫將在主鍵列上自然排序，所以我認為我可以使用 a) go 並且只需要一個索引。 有人可以確認嗎？

示例數據庫

CREATE TABLE `team_member` (
  `member_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `team_id` int(11) unsigned NOT NULL,
  `name` varchar(200) NOT NULL,
  ...
  (several more columns of info)
  ...
   PRIMARY KEY (`member_id`),
   KEY `IDX_TeamMember_TeamId` (`team_id`)
) ...

示例查詢

select *
from `member`
where `team_id` = 11111
order by `member_id`
limit 0,10

MySQL 服務器版本 5.6.10

非常大的桌子，規模是大問題

Answer 1

優化器更喜歡在查看ORDER BY之前完全處理WHERE子句。

除非整個WHERE 、 GROUP BY和ORDER BY由單個索引處理，否則無法有效處理LIMIT 。

優化器有時會跳過WHERE子句並根據ORDER BY查找索引。 這是你的建議。 但它必須使用“錯誤”的team_id掃描大量行。 在找到 10 行之前，它可能必須掃描整個表。 所以，這可能是一個“糟糕”的計划。

您可以人為地更改PRIMARY KEY來優化一些重要的查詢。 對於你的例子：

PRIMARY KEY(team_id, member_id),
UNIQUE(member_id)

UNIQUE保留您當前擁有的索引和唯一性檢查。 PK 必須是“唯一的”； 通過在其中包含member_id ，它可以保證是唯一的。 數據現在首先按team_id （因此將有效地處理WHERE ，然后按member_id排序，以便處理ORDER BY 。而且，因為它超過了這兩個，你的SELECT將觸及不超過 10 行（ LIMIT ).

使用那個 PK 和那個查詢，它不僅能夠在 10 行之后停止，而且這 10 行很可能在一個磁盤塊中。 （或者可能是少量的“連續”塊。）沒有比這更好的了。

是的，InnoDB 確實按 PK 對數據進行排序。

為什么目標只有一個索引？ 多個索引不是罪過。 這對INSERTs來說是一個非常小的負擔，但對某些SELECTs來說可能是一個很大的好處。

桌子有多大？ 即使對於十億行的表，我推薦的內容也很好。

復合索引第一列的選擇性（基數）是無關緊要的。 色譜柱組合的選擇性可能會起作用。 但是，您的示例不太可能受到影響。