調教MYSQL效能，SQL_NO_CACHE不讀取緩存

在使用 phpMyAdmin 測試 SQL 效能時，會發現同一條查詢第一次執行需要 3 秒，第二次卻只要 0.3 秒。這是因為 MySQL 的 Query Cache 機制在作用，導致測試結果失真。

MySQL Query Cache 機制

MySQL 的 Query Cache 會快取 SELECT 查詢的結果。當相同的 SQL 語句再次被執行，且相關的資料表沒有被修改時，MySQL 會直接從快取中回傳結果，不重新執行查詢。

這對於生產環境讀多寫少的場景有幫助，但在效能測試時卻會造成誤判，因為第一次是真實執行，之後的測試都是讀快取，根本無法反映 SQL 的真實效能。

注意：MySQL 8.0 已完全移除 Query Cache 功能，因為在高並發場景下 Query Cache 的鎖競爭問題反而會造成效能瓶頸。若使用 MySQL 8.0+，不需要擔心此問題。

使用 SQL_NO_CACHE 測試真實效能

在 SELECT 後加上 SQL_NO_CACHE 關鍵字，可以強制 MySQL 不使用快取，每次都重新執行查詢：

1

SELECT SQL_NO_CACHE * FROM orders WHERE status = 'pending';

這樣每次執行的時間才能反映 SQL 的實際執行效能，適用於：

• 調整索引前後的效能比較
• 分析慢查詢的真實耗時
• 壓力測試前的效能基準建立

注意：SQL_NO_CACHE 是 MySQL 5.x 的語法，MySQL 8.0 已移除，不再需要使用。

其他 MySQL 效能調教方法

1. EXPLAIN 分析查詢計畫

使用 EXPLAIN 可以查看 MySQL 如何執行一條 SQL，包含是否使用索引、掃描了多少列等資訊：

1

EXPLAIN SELECT * FROM orders WHERE status = 'pending' AND user_id = 123;

重要欄位說明：

• type：查詢類型，ALL 表示全表掃描（效能最差），ref/eq_ref 表示使用索引
• rows：預估掃描的資料列數，越少越好
• Extra：Using index 表示覆蓋索引，Using filesort 表示需要額外排序

2. 索引優化

適當建立索引是提升查詢效能最有效的方式：

1
2
3
4
5

-- 建立複合索引
CREATE INDEX idx_status_user ON orders(status, user_id);

-- 查看現有索引
SHOW INDEX FROM orders;

3. 慢查詢日誌（Slow Query Log）

在 my.cnf 中開啟慢查詢日誌，記錄超過指定時間的查詢：

1
2
3
4

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

開啟後可以使用 mysqldumpslow 分析慢查詢日誌，找出需要優化的 SQL。

參考資料

• Mysql 简单SELECT，第一次很慢，以后很快，这是什么问题 - ITPUB
• 你真的會用mysql 的SQL_NO_CACHE嗎？ - 每日頭條