MySQL主鍵會影響SELECT查詢的效率嗎？
除了唯一標識特定行之外，主鍵是否有其他用途？例如，具有自動遞增主 INT 鍵的表可以極大地幫助搜尋，因為它可能是二進制搜尋的選項；但是 MySQL 真的利用了這個選項嗎？
如果是這樣，主鍵是否需要按順序排列？當我們遇到這個問題時，如果一個表按特定列的順序排列——無論是否是主列——如果在 WHERE 子句中指定了該特定列，這是否有助於 SELECT 過程？
如果沒有，在為我的數據庫建構高效的基礎架構時，我可以採取哪些預防措施？例如，我有一個文章表，其中前兩列是：作為主鍵的“ID”和作為 URL 的字母數字 ID。為了顯示相關文章，我有一個包含兩列相關文章 ID 的表格。我注意到當“相關”表記錄主鍵（‘ID’）而不是字母數字 ID（不是主鍵也不是數字）時，多表 SELECT 查詢要快得多。
InooDB 的所有東西，
PRIMARY KEY都扮演著重要的角色。正如ypercube在回答末尾提到的那樣，InnoDB 使用集群鍵結構，用於集群的鍵是PRIMARY KEY.盡可能小的佔用空間是非常
PRIMARY KEY重要的：索引的深度是您必須支付的最低費用才能到達葉節點。InnoDB 的深度PRIMARY KEY是任何索引搜尋的起始費用。我的一般建議是
AUTO_INCREMENT對 InnoDB 使用主鍵。以下是我的三篇部落格文章支持這一點：
一
INT列是 4 個字節。如果沒有關於 alphanumericID 的更多詳細資訊，我假設它是一個VARCHAR(40)（其中 40 可以是任何數字）。related_articles 表可能在一種情況下（8 字節寬）和另一種情況下（80 字節寬）有一個
PRIMARY KEYon 。如果字元集是 UTF-8 而不是拉丁語，那麼在最壞的情況下（UTF-8 需要每個字元 1 到 3 個字節），它將是（240 字節寬）的三倍。(ID1, ID2)``(alphaID1, alphaID2)通常這些表也有一個
(ID2, ID1)索引。因此，第一種情況下的索引每行 16 個字節，第二種情況下每行 160 個字節（第三種情況下最多 480 個字節）。這意味著任何將使用此（主）索引的查詢都能夠從磁碟上的索引載入 10 倍以上的數據（如果 varchars 是 UTF，則為 30 倍）到相同數量的記憶體空間。由於磁碟是最慢的部分，如果需要大部分索引，這也意味著大約快 10 倍。
而且由於記憶體 (RAM) 對數據庫來說是最有價值的，因此可以節省任何數量，這意味著更大的索引和更多的索引可以保留（記憶體）在記憶體中，然後用於後續查詢，而無需從 (慢）磁碟。
（在 4 字節列上執行連接也比在 40 字節列上更有效，但這並不能解釋性能上的巨大差異。）
另請注意，對於 InnoDB 表，選擇
PRIMARY KEY（或第一個UNIQUE，如果您尚未定義主）作為聚集鍵。並且它的列被添加到所有其他索引中。因此，這個聚集鍵越寬，所有其他索引的空間就越大。例如，假設
article表有 5M 行，而表related_articles有 30M 行。在第一種情況下，related_articles 的索引需要大約半 GB。在第二種情況下，這將是 5GB（在壞情況下為 15GB）。