1. 使用 NOT 、!=、not in、not like 等負向判斷詞：
SELECT * FROM users WHERE name != 'John';
2. 使用函數語句包裝被索引的欄位：
SELECT * FROM users WHERE DATE(created_at) = '2022-02-28';
這邊的範例使用 DATE() 函數，去轉換 created_at 這個欄位，因而導致無法透過原始資料，去觸發索引機制。
這邊要幫大家建構一個概念，索引會失效很重要的核心問題就是，『不要對欄位動手腳』，後續會用其他例子幫大家更釐清會有什麼情境。
3. 資料類型錯誤：
SELECT * FROM users WHERE age = 30;
這邊假設 age 設定 varchar ，也就是字串型別，則 SQL 在判斷時，會『偷偷的』去做類別轉換，也就是對欄位動手腳，就會導致索引失效。
4. 使用 『 %XXX% 』或是 『 %XXX 』：
SELECT * FROM users WHERE name like '%john%';
失效的原因，是因為索引運算機制中，有部分會從字元最左開始匹配，如果用範例的搜尋模式，『 最左 』的字元會無法匹配，導致失效。
5. 使用 Null：
SELECT * FROM users WHERE name IS NULL;
Null 值對於 Index 資料管理來說是比較迥異的存在，所以通常預設是不支援的，但在部份資料庫軟體中，可以另外設定讓 Null 被納入索引中。
6. 錯誤的使用 or：
SELECT * FROM users WHERE indexed_column > 5 or unindexed_column < 10;
上面的語句中， indexed_column 是有被加入索引的欄位，而 unindexed_column 是沒有被加入索引的欄位。
如果 query 語句中，含有沒有被加入索引的欄位，則索引不會生效。
7. 針對索引欄位做運算：
SELECT * FROM users WHERE height - 10 > 150;
這邊可以再帶回我們上面強調的概念，對欄位動手腳的話，索引即不會生效，所以上面的例子中，對 height 做了運算，會導致索引無效。
8. 複合式 INDEX 使用順序錯誤：
假設有三個欄位合起來的索引，name + height + weight
SELECT * FROM users WHERE name = 'john' and weight > 100;
上面語句的問題是，我們的索引是從 name 起頭，再來是 height，可是這個語句直接先接上了 weight，就會導致索引失效。
所以上面語句合法的索引組合有三：
name + height + weight
name + height
name
跳脫這三者的排序，則會讓索引失效。
資料庫的索引功能是資料庫中一種非常重要的技術，它可以讓我們更快速地查找和搜尋資料。想像一下，如果資料庫就像一個龐大的書櫃，裡面有成千上萬本書（也就是資料）。如果我們要找到某本特定的書，如果沒有任何規劃，我們得一本一本地去翻，這樣費時又費力。但如果有個好的索引，就像有個便捷的目錄，我們只需查閱目錄中的索引詞，就能快速找到需要的書籍。
在資料庫中，索引的作用就類似於這個目錄，它是一個特殊的資料結構，能夠對資料表中的某個欄位（或多個欄位）進行排序和組織，從而加快查詢的速度。當我們在資料表中建立了索引後，資料庫系統會根據索引的規則，將資料庫中的資料排列有序，這樣在執行查詢時，它就可以更快速地找到我們需要的資料。
舉例來說，假設我們有一個包含成千上萬筆顧客資料的資料表。現在，我們想查詢姓氏為「王」的顧客，如果沒有索引，資料庫就得從頭到尾一筆一筆地檢查每個顧客的姓氏，直到找到符合條件的記錄。這樣的查詢速度會相當緩慢，尤其當資料量非常大時。但是，如果我們在「姓氏」這個欄位上建立了索引，資料庫就會事先將這些顧客按照姓氏的順序排列，當我們查詢姓氏為「王」時，資料庫只需快速地在索引中找到「王」這個項目，然後直接定位到這些顧客的記錄，這樣就大大加快了查詢的速度。
簡單來說，索引就是為了讓我們更快地找到資料。在資料庫中，建立適當的索引非常重要，特別是當資料量大時，索引能夠顯著地提升查詢效能，讓我們的應用程式運行更順暢。然而，索引也不是萬能的，過多或不當的索引可能會增加資料庫的存儲成本，並降低寫入操作的效率。因此，在建立索引時，我們需要仔細考慮資料表的特性和常見的查詢需求，確保適度而有效地使用索引。
