MySQL 索引加了還是慢？資深工程師揭秘 5 個 WordPress 索引失效的效能黑洞 (附程式碼)

哈囉，我是浪花科技的資深工程師 Eric。寫程式這麼多年，最常在 code review 或救援專案時看到一個經典場景：網站後台卡到天荒地老，客戶抱怨連連。年輕工程師一臉無辜地說：「有啊！我有加索引啊！你看，每個欄位都加了！」然後我打開資料庫一看，眉頭一皺，發現事情並不單純。這真的是工程師的日常，索引就像是網站效能的萬靈丹，但很多人只知其一，不知其二，以為「有加就好」，結果就是加了一堆「安慰劑索引」，對查詢效能一點幫助都沒有，反而拖慢了寫入速度。

今天，我就來當一次討人厭的資深工程師，好好「囉嗦」一下，帶你揭開那些讓你的 MySQL 索引優化與效能調教 失敗的效能黑洞。這不只是理論，這全都是我們在無數個 WordPress 專案中踩過的坑、流過的淚。準備好了嗎？讓我們來看看，為什麼你精心建立的索引，MySQL 可能連看都沒看一眼！

為什麼索引不是「有加就好」？先搞懂它的成本

在我們深入探討索引失效的地雷之前，得先建立一個核心觀念：索引是有成本的。它不是免費的午餐。很多人把它想像成書本的目錄，可以光速找到資料，這沒錯。但你得知道，這個「目錄」本身是需要空間儲存的，而且每次你新增、修改、刪除書本內容時，目錄也得跟著更新。

這轉換到資料庫的世界就是：

• 儲存成本： 索引會佔用硬碟空間，有時候一個複雜的索引甚至可能比資料本身還大。
• 寫入成本： 每當你執行 INSERT、UPDATE、DELETE 操作時，資料庫不僅要修改資料表，還要更新所有相關的索引。索引越多，寫入操作就越慢。

所以，亂加索引就像是為一本只有十頁的小說，做了二十頁的目錄，完全是本末倒置。我們的目標是「精準索引」，只在必要的地方建立高效的索引，而不是盲目地「火力覆蓋」。

地雷一：複合索引的順序搞錯，MySQL 直接跟你說掰掰

這是最常見，也最致命的錯誤。當你的查詢條件（WHERE 子句）涉及多個欄位時，你可能會想建立一個包含這些欄位的「複合索引」。例如，在 WooCommerce 網站中，你可能需要查詢所有「已發佈」的「產品」。

這個查詢會牽涉到 wp_posts 資料表的 post_type 和 post_status 兩個欄位。新手可能會這樣下指令：

-- 一個看似合理，但可能效率不彰的查詢
SELECT ID, post_title 
FROM wp_posts 
WHERE post_type = 'product' AND post_status = 'publish';

然後想說，好，我來建個索引！於是就隨便建了一個：

-- 錯誤示範！
ALTER TABLE `wp_posts` ADD INDEX `idx_status_type` (`post_status`, `post_type`);

問題來了，為什麼這個順序可能是錯的？你必須理解 MySQL 索引的「最左前綴原則 (Left-Prefix Rule)」。簡單說，MySQL 在使用複合索引時，必須從索引的最左邊欄位開始，依序向右匹配。如果查詢條件沒有用到索引的第一個欄位，那整個索引基本上就廢了。

如何決定正確的順序？

原則很簡單：把篩選後剩下資料最少的欄位放最前面。也就是「選擇性高 (Cardinality)」的欄位優先。在 post_type 和 post_status 中，post_type 的值可能有 ‘post’, ‘page’, ‘product’, ‘attachment’ 等等，而 post_status 通常是 ‘publish’, ‘draft’, ‘trash’, ‘pending’。通常情況下，一個網站的 post_type 種類會比 post_status 多，且 `post_type = ‘product’` 能篩掉更多不相關的資料。所以，正確的索引順序應該是：

-- 正確的複合索引順序
ALTER TABLE `wp_posts` ADD INDEX `idx_type_status` (`post_type`, `post_status`);

這個索引，對於上面的查詢就能完美命中。如果你把順序搞反，當 MySQL 看到 post_status 時，它可能會發現符合 ‘publish’ 的資料太多了（大部分文章都是發佈狀態），導致它覺得走索引還不如直接掃描全表來得快，於是你的索引就被華麗地忽略了。

地雷二：索引欄位上使用函數或運算，等於自廢武功

第二個常見的坑，就是在 WHERE 條件中對索引欄位進行函數運算、型別轉換或計算。這等於是告訴 MySQL：「嘿，我把這個欄位改頭換面了，你原本認識的那個索引目錄用不上了喔！」

舉個 WordPress 開發中很常見的例子：你想撈出今年所有發佈的文章。你可能會很直覺地這樣寫：

-- 索引失效的寫法！
SELECT ID, post_title 
FROM wp_posts 
WHERE YEAR(post_date) = 2025;

即便 post_date 欄位上有索引，這個查詢也絕對用不到。因為 MySQL 必須對每一行的 post_date 值都執行一次 YEAR() 函數，才能得到結果來跟 2025 比較。這個過程使得索引完全無法發揮作用。

正確的作法是，保持索引欄位的「純淨」，把運算移到條件值的另一邊：

-- 能夠有效利用索引的寫法
SELECT ID, post_title 
FROM wp_posts 
WHERE post_date >= '2025-01-01 00:00:00' AND post_date < '2026-01-01 00:00:00';

這樣一來，MySQL 就可以直接利用 post_date 上的索引，進行高效的範圍掃描 (Range Scan)。記住這個鐵則：不要對索引欄位動手動腳！

地雷三：LIKE 查詢的隱形殺手 — 百分比 (%) 放錯邊

在 WordPress 後台做內容搜尋時，LIKE 查詢是家常便飯。但它的用法也藏著效能陷阱。同樣基於「最左前綴原則」，如果你的 LIKE 查詢是以萬用字元 % 開頭，那索引也幫不了你。

-- 索引失效：前導萬用字元
SELECT * FROM wp_posts WHERE post_title LIKE '%關鍵字%';

-- 索引有效：後置萬用字元
SELECT * FROM wp_posts WHERE post_title LIKE '關鍵字%';

為什麼？想像一下查字典，你要查 `apple` 開頭的單字，你可以很快翻到 ‘a’ 的部分。但如果要你找出所有 `ple` 結尾的單字，你除了把整本字典從頭翻到尾，別無他法。LIKE '%關鍵字%' 就是這種情況，它迫使 MySQL 進行全表掃描 (Full Table Scan)，在資料量大時絕對是一場災難。

如果你的應用場景真的需要全文檢索，請不要硬幹 LIKE '%...%'。考慮使用 MySQL 內建的 FULLTEXT 索引，或是更專業的搜尋引擎方案，例如 Elasticsearch 或 Algolia。這才是治本之道。

進階策略一：用「覆蓋索引」讓查詢飛起來

講完了地雷，我們來講點能讓你同事對你刮目相看的進階技巧 — 覆蓋索引 (Covering Index)。

所謂的覆蓋索引，就是一個索引本身就包含了查詢所需的所有欄位（SELECT 和 WHERE 子句中提到的所有欄位）。當這種情況發生時，MySQL 就可以只讀取索引，完全不需要再去讀取資料表本身的資料，這個過程稱為「Index-only scan」。因為索引通常比資料表小得多，讀取 I/O 大幅減少，速度自然快得驚人。

假設我們需要一個功能，快速列出某個產品 (post_id=123) 的所有自訂欄位 key 和 value。這個資料儲存在 `wp_postmeta` 表。

SELECT meta_key, meta_value 
FROM wp_postmeta 
WHERE post_id = 123;

WordPress 預設在 wp_postmeta 的 post_id 上有索引。但這個查詢，MySQL 找到符合的 `post_id` 後，還需要根據索引中的位置「回表」去撈 meta_key 和 meta_value。如果我們建立一個覆蓋索引：

-- 建立一個覆蓋索引
ALTER TABLE `wp_postmeta` ADD INDEX `idx_post_key_value` (`post_id`, `meta_key`, `meta_value`(255));
-- 注意：meta_value 是 longtext，建立索引時需要指定長度

有了這個索引，MySQL 在處理上面的查詢時，會發現 `post_id`, `meta_key`, `meta_value` 這三個欄位都在 `idx_post_key_value` 這個索引裡了。它只需要掃描這個小小的索引，就能拿到所有需要的資料，連 `wp_postmeta` 資料表本體都不用碰。用 EXPLAIN 分析這個查詢，你會在 Extra 欄位看到 `Using index` 的字樣，這就是效能的保證！

進階策略二：避開低選擇性（Low Cardinality）索引的陷阱

最後一個囉嗦，是關於索引的「選擇性 (Cardinality)」。它指的是一個欄位中不重複值的數量。選擇性越高，代表這個欄位的值越獨特，索引的效果就越好。反之，如果一個欄位只有很少幾種值（例如：’yes’/’no’，’male’/’female’），那在這個欄位上建立索引的意義就不大。

例如，你在 `wp_usermeta` 中增加了一個欄位 `is_vip`，值只有 0 或 1。如果你想查詢所有 VIP 用戶：

SELECT user_id FROM wp_usermeta WHERE meta_key = 'is_vip' AND meta_value = '1';

在 `meta_value` 上單獨建立索引幾乎是沒有意義的。因為 `meta_value = ‘1’` 可能會篩選出將近一半的用戶，MySQL 會認為直接掃描全表可能更快。在這種情況下，建立一個 `(meta_key, meta_value)` 的複合索引會是更明智的選擇。

結論：成為一個懂思考的索引設計師

MySQL 索引優化與效能調教是一門藝術，而不僅僅是技術。它需要你理解業務邏輯、分析查詢模式，而不只是盲目地執行 ADD INDEX。下次當你遇到慢查詢時，不要急著加索引，先拿出 EXPLAIN 工具來分析，問問自己：

• 我的複合索引順序對嗎？
• 我在索引欄位上做運算了嗎？
• 我的 LIKE 查詢方式正確嗎？
• 我能用覆蓋索引來避免回表嗎？
• 這個欄位的選擇性高嗎？值得建索引嗎？

把這些問題刻在腦子裡，你就能從一個只會「貼OK繃」的工程師，蛻變成一個能「動手術」的效能調校專家。這也是拉開你和別人技術差距的關鍵所在。別再讓你的索引睡大覺了，讓它們真正為你的網站效能工作吧！

—

延伸閱讀

• 網站慢如牛，元兇竟是它？資深工程師帶你用 EXPLAIN 解剖 WordPress 資料庫，揪出 MySQL 效能惡棍！
• WP_Query 不是只會 `post_type`！資深工程師的進階查詢食譜，從 Meta Query 到效能調校的屠龍術
• 別讓你的資料庫變『麵團』！資深工程師的 WordPress MySQL 資料表設計終極實戰心法

如果你對 WordPress 網站的效能問題感到頭痛，或是需要更深入的資料庫架構諮詢與健檢，浪花科技的團隊擁有豐富的實戰經驗，能幫助你找出效能瓶頸，打造穩定且高效的網站。不要再忍受龜速的後台了，立即聯繫我們，讓專業的來！