SQL在一個表上創建多列索引和單列索引

Question

我有一個表格說產品。
其具有以下columms：
ID
AdminID
類別ID
此表上的某些查詢將是僅在AdminID（Q1）和一些僅在類別ID（Q2）。然而，兩者上的詢問很少，即AdminID和CategoryID（Q3）。
看來，在這種情況下，我需要創建2個指數（不包括ID的那個）：兩個AdminID和類別ID

• 指數與指數AdminID的位置爲1。這應該處理Q1和Q3。
• 僅限索引類別ID。這應該處理Q2。

高於一個好的設計？

Answer 1

簡短的回答是 - 是的，沒關係。如果數據的使用保證，在需要時做索引是「好設計」。

較長的答案是肯定的，有一些考慮因素;

表中的數據量爲索引提供了保證，這意味着維護更新中的數據，插入和刪除多個索引時的開銷，而不是僅從每個查詢的表中提取所有數據。
基本上 - 例如，如果表中不包含「大量數據」，那麼避免將索引全部放在一起可能會更好。
也是如何分配？如果數據的80％（例如數字）在字段/列中具有相同的值，則索引對選擇可能不太有用，因爲查詢優化器無論如何仍將基本上接觸大多數行，因此開銷在維持指數方面可能要大於選擇指數的收益。

也不知道你的數據庫設計（相關表）的其餘部分，不可能說你的結構是否是「最優」的，並且你是否真的需要這個表中的值，或者他們應該在另一個表中，或者你的查詢可能會改變。

Answer 2

一般來說（忽略RDBMS規範），您可以考慮Products表中的任何索引是包含基於索引列的Products表的排序數據的另一個表。這將是一個有效的結構，當searching the table based on the index column。

在另一方面，任何表具有索引將對插入，更新的性能損失和刪除表操作由於指數的同步的成本（索引結構需要被保持排序）。

AdminID和CategoryID外鍵，其建議在他們每個人的指數，該指數將防止Products表時刪除或更新發生在Category或Admin(user)表也將幫助查詢性能被鎖定。

在AdminID + CategoryID上有一個複合索引將是事務性能和查詢性能之間的折衷。這需要通過分析數據庫來找到很好的理由。
MySQL能夠登錄時間超過指定的時間閾值來執行查詢，調用它slow query log及其long_query_time時間參數默認爲10秒。
提名慢查詢後，您需要通過分析查詢的查詢執行計劃（QEP）來查看原因，然後確定索引創建或刪除。

Know your data, know your queries, and MENTOR your indexes。

Answer 3

你是正確的。你只需要創建兩個索引：（AdminID，CategoryID）和（CategoryId），因爲AdminID包含CategoryID，當優化器認爲它符合成本效益時，將使用AdminID。沒有理由創建單獨的AdminID索引。