索引優化的核心在于合理使用索引來提升mysql查詢性能。1. 索引不是越多越好，應根據查詢模式選擇合適字段創建索引；2. b-tree適合范圍查詢和排序，hash適合等值查詢；3. 避免索引失效的常見原因如or條件、like以%開頭、在索引列上進行計算、類型不匹配、未遵循最左前綴原則；4. 聯合索引順序應優先放置選擇性高的列；5. 使用explain分析執行計劃，關注type、key、rows、extra等關鍵信息；6. 定期使用optimize table或重建索引維護索引效率。通過這些方法可有效提升查詢速度并減少資源消耗。
索引優化，說白了就是讓mysql更快地找到你想要的數據。創建索引不是越多越好，用對地方才是關鍵。
索引優化，簡單來說，就是讓查詢更快。最佳實踐包括合理創建索引、避免索引失效，以及利用MySQL的查詢優化器。
索引類型選擇：B-Tree還是Hash？
這個問題其實沒有絕對的答案，取決于你的具體場景。B-Tree索引（InnoDB默認）適合范圍查詢和排序，而Hash索引（Memory引擎默認）適合等值查詢。如果你經常需要>、
選擇索引類型時，要考慮你的查詢模式。另外，也要注意存儲引擎的支持情況。InnoDB只顯式支持B-Tree索引，而Memory引擎支持Hash和B-Tree。
如何避免索引失效？
索引失效是性能殺手。常見的原因包括：
- 使用OR條件，但OR兩邊的列沒有都建立索引。 這種情況下，MySQL可能會放棄使用索引，全表掃描。
- LIKE查詢以%開頭。 比如LIKE ‘%abc’就無法使用索引。
- 在索引列上進行計算或函數操作。 比如WHERE YEAR(date_column) = 2023。
- 類型不匹配。 比如索引列是字符串類型，但查詢條件是數字類型。
- 聯合索引，但查詢條件沒有使用索引的最左前綴。 比如你創建了INDEX(a, b, c)，但查詢條件只有WHERE b = xxx AND c = xxx，就無法使用索引。
- MySQL認為全表掃描比使用索引更快。 這種情況比較少見，但確實存在。比如表很小，或者索引選擇性很差。
解決這些問題的方法也很簡單：避免使用OR，盡量避免LIKE ‘%abc’，不要在索引列上進行計算或函數操作，保持類型匹配，遵循最左前綴原則。如果MySQL認為全表掃描更快，可以嘗試FORCE INDEX強制使用索引，或者優化查詢語句。
聯合索引的順序如何確定？
聯合索引的順序非常重要。一般來說，應該把選擇性最高的列放在最前面。選擇性是指，不重復的索引值與表記錄總數的比值。選擇性越高，索引的效果越好。
你可以通過select count(DISTINCT column_name) / COUNT(*) FROM table_name來計算列的選擇性。
另外，也要考慮查詢模式。如果你的查詢經常只使用索引的前幾列，那么這些列就應該放在聯合索引的最前面。
舉個例子，如果你有一個用戶表，包含country、province、city三個字段，并且經常需要根據這些字段進行查詢，那么你可以創建一個聯合索引INDEX(country, province, city)。如果country的選擇性最高，city的選擇性最低，那么這個順序就是合理的。
如何利用EXPLaiN分析查詢語句？
EXPLAIN是MySQL提供的非常有用的工具，可以用來分析查詢語句的執行計劃。通過EXPLAIN，你可以看到MySQL是否使用了索引，使用了哪個索引，以及查詢的性能瓶頸在哪里。
EXPLAIN會返回很多列，其中比較重要的包括：
- type： 表示查詢使用了哪種訪問類型。常見的類型包括system、const、eq_ref、ref、range、index、ALL。一般來說，type越好，查詢性能越高。ALL表示全表掃描，是最差的類型。
- possible_keys： 表示MySQL可以使用哪些索引。
- key： 表示MySQL實際使用了哪個索引。
- key_len： 表示MySQL使用的索引的長度。
- ref： 表示哪些列或常量被用于查找索引列上的值。
- rows： 表示MySQL需要掃描多少行才能找到結果。
- Extra： 包含一些額外的信息，比如是否使用了臨時表，是否使用了文件排序等。
通過分析EXPLAIN的結果，你可以找出查詢語句的性能瓶頸，并進行優化。比如，如果type是ALL，表示全表掃描，那么你需要考慮添加索引。如果Extra包含using temporary或Using filesort，表示使用了臨時表或文件排序，那么你需要優化查詢語句或索引，避免這種情況發生。
索引維護：定期優化和重建索引
索引不是一勞永逸的。隨著數據的增刪改，索引可能會變得碎片化，影響查詢性能。因此，需要定期對索引進行維護。
MySQL提供了OPTIMIZE TABLE語句，可以用來優化表。OPTIMIZE TABLE會重新組織表的物理存儲，重建索引，消除碎片。但是，OPTIMIZE TABLE會鎖表，因此應該在業務低峰期執行。
另外，如果你的表經常進行大量的刪除操作，或者索引的碎片化非常嚴重，那么可以考慮重建索引。重建索引可以使用ALTER TABLE table_name DROP INDEX index_name, ADD INDEX index_name (column_list)語句。重建索引也會鎖表，因此也應該在業務低峰期執行。
索引優化是一個持續的過程，需要不斷地學習和實踐。希望這些建議能幫助你更好地優化mysql索引，提升查詢性能。
