MySQL索引有什麼好處，如何合理新增？

要構建乙個好的索引，主要是構建查詢多的列，where條件多的列，需要排序的列。建立多個復合索引。

總而言之，索引有三個主要好處：

1.索引大大減少了伺服器要掃瞄的資料量。

2. 索引可以簡化為隨機io，改為順序io。

3. 索引可以幫助伺服器避免排序和臨時表。

索引可以加快資料檢索操作的速度，但會降低資料修改操作的速度。 每次修改資料記錄時，都必須重新整理索引。 為了在一定程度上彌補這一點，許多 SQL 命令都有乙個延遲鍵寫入項。

此選項的作用是暫時阻止 mysql 在插入每個新記錄和命令修改每個現有記錄後立即重新整理索引，並且在插入和修改所有記錄之前不會重新整理索引。 在需要將許多新記錄插入到表中的情況下，延遲鍵寫入選項將非常有用。

此外，索引會占用硬碟上的大量空間。 因此，只應為最常查詢和最常排序的資料列編制索引。 如果一列資料包含大量重複內容，則對其進行索引不會產生太大的實際效果。

索引分為單列索引和組合索引。

單列索引，即乙個索引只包含一列，乙個表可以有多個單列索引，但這不是組合索引。

組合索引，即包含多列的索引。

建立索引時，需要確保索引是應用於 SQL 查詢語句的條件（通常作為 WHERE 子句的條件）。

實際上，索引也是乙個包含主鍵和索引欄位並指向實體表記錄的表。

以上都談到了使用索引的好處，但使用過多的索引會導致濫用。 所以索引也有其缺點：

索引雖然大大提高了查詢速度，但它們也會減慢更新表的速度，例如插入、更新和刪除表。 更新表時，MySQL不僅儲存資料，還儲存索引檔案。

為占用磁碟空間的索引檔案編制索引。

from shulanxt

索引就像一本書的目錄，例如，如果你想閱讀一本書的第20章，你會先在目錄中檢視第20章的頁數，然後立即翻到第20章的頁數，而不是一頁一頁地翻。

索引將首先按一定順序排列索引列，以便再次找到它會快得多。

為 MySQL 資料庫中的字段編制索引意味著對資料庫中表中的一列或多列中的值集合進行排序，以及指向表中物理標識這些值的相應資料頁，這些值是邏輯指標列表。

索引提供指向儲存在表的指定列中的資料值的指標，然後根據指定的排序順序對這些指標進行排序。 資料庫使用索引來查詢特定值，然後沿著指標指向包含該值的行。 這樣可以更快地執行與表對應的 SQL 語句，從而可以快速訪問資料庫表中的特定資訊。

以下規則通常用於索引：

1、表的主鍵和外來鍵必須有索引;

2.資料超過300個的表應有索引;

3. 對於經常與其他表聯接的表，應在聯接欄位上建立索引;

4. 經常出現在 where 子句中的字段，尤其是大表中的字段，應該索引;

5. 索引應建立在高度選擇性的字段上;

6、索引要建立在小字段上，對於大文字字段甚至超長字段，不要搭建索引;

7、復合指標的建立需要仔細分析; 嘗試考慮改用單字段索引： a. 正確選擇復合索引中的主列字段，通常是選擇性較好的字段; 灣。在 AND 模式下，復合索引的多個字段是否經常同時出現在 where 子句中？單字段查詢很少或沒有？

如果是這樣，您可以構建復合索引; 否則，請考慮單字段索引; 三.如果復合索引中包含的字段經常單獨出現在 where 子句中，則它們將被分解為多個單字段索引;d.如果復合索引包含3個以上的字段，那麼請仔細考慮其必要性，並考慮減少復合欄位的數量;e.如果這些欄位上同時存在單字段索引和復合索引，則通常可以刪除復合索引;

8. 不要為頻繁執行資料操作的表建立過多的索引;

9、刪除無用的索引，避免對執行計畫產生負面影響; 這些是索引的一些常見標準。 總之，指標的建立必須認真做好，每個指標的必要性都要仔細分析和建立。 因為索引太多，索引不足，不正確的索引對效能不利

在表上建立的每個索引都會增加儲存開銷，索引會增加插入、刪除和更新操作的處理開銷。 此外，復合索引過多，在單字段索引的情況下，通常沒有價值; 相反，當將資料新增到刪除時，它也會降低效能，尤其是對於頻繁更新的表，這會產生更大的負面影響。

你現在的方法的效率其實差不多，都是很低的，極低的，最低的。

1.如果你不提高效率，只是簡化程式，我建議你對新聞類目進行二進位編碼，還是用乙個特徵欄位來表示它，這個欄位是整數型別，用開頭的四個二進位位在最低點是否為1來表示是否是**新聞， headlines、homepage news 和 important news，例如 7（二進位 0111）表示它有三個屬性：headlines、homepage 和 important。查詢時，使用位運算&實現，**news、headlines、homepage news和重要新聞權重分別為，此時，如果呼叫三個是**news的新聞，可以直接使用SQL語句：

select * from news where features & 8=8 order by news_id desc limit 0,3;

select * from news where features & 9=9 order by news_id desc limit 0,3;

如果看到沒有，可以查詢乙個屬性或多個屬性的資料，程式非常方便。

其次，有效的方法是設定另乙個表來記錄各種新聞，冗餘地將資料儲存到多個表中，並在哪個表中查詢需要查詢哪些新聞。 但是程式會很複雜，會根據分類儲存在不同的表中，修改起來最麻煩，如果改變分類，還需要將資料從乙個表移動到另乙個表。 當然，作為新聞這樣的應用，儲存一次，修改一次，修改一次，瀏覽上千次，對於整體效率來說，這當然是優化查詢的關鍵**。

另外，站長群上還有產品**，便宜***。

刪除資料、修改索引欄位和新增新操作將維護索引，維護成本很高。

同時，需要更多的磁碟空間。

要綜合平衡，發揮最大優勢。

如果未用於搜尋的字段已編制索引，則會導致插入，並且更新速度較慢，因為索引表正在更新。

讓我們先面對你的問題。

資料是否重複不是索引的重要依據，甚至不是依據。

只要它不是完全重複的（該元素對於所有元組都是相同的），那麼索引是有意義的。

就算現在的資料完全複製，構建索引也不是不可能，這有點複雜，不會詳細。

對於你以後的問題，我可以給你乙個關於如何建立索引的建議，“如何查詢它”。

索引的唯一原因是查詢（generalized query），其實索引會讓資料儲存占用的空間變大，有時索引占用的空間會檢查資料本身的空間。 索引建立也會使資料插入變慢，在某些情況下會讓人難以忍受，因此 DBA 的重要任務之一就是檢查索引層次結構並對其進行優化。

索引的唯一好處是按索引查詢時速度更快。 type 和 status 這兩個字段是否適合索引，取決於是否要根據這兩個字段進行搜尋。 搜尋的順序決定了索引的生成方式。

對於索引型別和索引方法，我建議這樣做。

normal

和。 btree

它在大多數情況下都有效。 如果你涉及乙個大資料處理專案，對資料儲存和檢索有特殊要求，那麼在考慮是否使用聚簇索引之前，需要分析多個層次的資料吞吐量、資料方差、平均偏差等諸多引數（mysql似乎還沒有聚簇索引），至於是否是唯一索引， 我建議不要使用它，即使您可以確定資料是唯一的，也不要使用它，並且不需要全文索引。