多個或單個複合索引

假設您有一個包含大約100萬行的id,a,b,c,d,e,f,g的表格。然後可以用多種組合的方式進行多個WHERE ...AND...AND...etc條件的查詢。這就是例如a AND b AND e或a AND f AND g或e AND f AND g。多個或單個複合索引

因此爲了解釋所有組合，您將不得不創建多個複合索引，但如果a,b,c,d,e,f,g的範圍是[1,10]，那麼不會有零。

難道一個只是讓每個起始變單一的化合物，從而a,b,c,d,e,f,g和b,a,c,d,e,f,g等。而在查詢時間做這樣的事情

#b and e have not been chosen 
    SELECT * FROM WHERE a=3 AND b!=0 AND c=4 AND d=5 AND e!=0 AND f=1 AND g=9 
    #I think you get the logic

難道這樣的程序讓MySQL的仍然使用複合索引還是我真的需要創建複合索引的所有可能的組合。

最終結果是索引的數目減少到7，而不是左組合候選條件的數目是方式高於7

來源

2016-04-25 delmalki

這種問題有時是缺乏規範化的症狀 – Strawberry

這是模擬mysql中的物化視圖，因此列數很大。 – delmalki

草莓確實有一個標準化點，只要你的a-g列都是相同的上下文。但是，如果你的數據是每個a-g列都有它自己的標準化值 - 比如我在一個政府合同表中工作。根表有超過20個單獨的查找參考表的鏈接，每個參考表都標準化爲ID。如果您可以擴展更多的通用a-g上下文，我們可以爲您的情況提供更好的說明和輸入。 – DRapp

如果可以MySQL將使用複合索引爲了。所以如果你的數據代表了一個單一的索引將會做的分類。比方說，客戶可以鍵入無論是企業還是個人，以及生活在一個給定的郵政編碼，並且狀態溢價或定期，然後像

SELECT * FROM customer 
WHERE type = 'business' 
AND postal_code = '12345' 
AND status = 'premium';

查詢將基於建立一個複合鍵可以使用索引type + postal_code + status。如果您不知道status，該指數仍然有用。但如果你只有知道postal_code但不是type，索引將不會被使用 - 順序很重要。

但我同意來自Strawberry的評論 - 這通常不是標準關係模式中的問題。在表中放置幾個外鍵並不罕見，但除非您正在構建數據立方體或其他特殊設計，否則這個問題不是您可能應該擁有的問題 - 當然不包含7個字段。

但是，如果這是一個真正的問題，請考慮每個潛在索引字段的值。如果大多數查詢能夠使用多個索引（複合或非複合）將百萬行縮小到幾千，則最終掃描可能是微不足道的。嘗試使用EXPLAIN PLAN來查看它停止對大多數查詢的重要性。

維護索引的成本可能是微不足道的。在高度調整的事務處理系統中，單次插入，更新或刪除將導致N + 1次寫入：一次是針對行，另一次是針對每個索引。如果你主要閱讀，那麼這可能是好的。如果不是，那麼通過減少寫入次數，複合鍵的某些組合可能會帶來一些好處。

但我一直在使用關係數據庫超過幾十年。出現這種情況的案例幾乎總是通過反思模式設計來解決;我不記得在典型的關係和規範化的模式中複合鍵比多個索引更有意義的情況。

來源

2016-04-25 01:31:56

多個或單個複合索引

回答

相關問題