MySQL 使用 LIMIT 1 優化查詢效率：百萬數據實測提速 2 倍

核心結論

在**無索引**或**非唯一索引**的大表上，查詢預期只返回一條記錄時，加上 LIMIT 1 可讓 MySQL 掃描到第一條匹配行即停止，**避免全表掃描**，顯著降低延遲。

實測數據 (100 萬條測試表)

原理解析

• MySQL 執行器按順序讀取數據頁，評估 WHERE 條件。
• 無 LIMIT：必須掃描**整張表**確認是否還有其他匹配行。
• 有 LIMIT 1：找到第一條匹配行即終止查詢，返回結果。

關鍵前提：列上**無唯一索引**

如果 username 有 **唯一索引** (或主鍵)，MySQL 優化器知道最多返回 1 行，**自動優化為單行讀取**，此時 LIMIT 1 無額外收益 (甚至極微增加解析開銷)。

適用場景清單

1. 業務邏輯保證唯一，但未建唯一索引 (如歷史表、臨時表、外鍵引用列)。
2. 只需任意一條匹配記錄 (如檢查是否存在、隨機抽樣、獲取最新一條配合 ORDER BY id DESC LIMIT 1)。
3. 非覆蓋索引查詢：需回表查詢列，LIMIT 1 減少回表次數。

反模式警示

-- ❌ 錯誤：LIMIT 1 掩蓋了數據質量問題 (實際有重複數據)
SELECT * FROM orders WHERE user_id = 123 LIMIT 1; 

-- ✅ 正確：業務上應保證唯一，建立唯一索引
ALTER TABLE orders ADD UNIQUE KEY uk_user_id (user_id);
-- 然後可直接查，無需 LIMIT 1
SELECT * FROM orders WHERE user_id = 123;

進階：LIMIT 1 配合 ORDER BY 陷阱

-- 獲取最新訂單
SELECT * FROM orders WHERE user_id = 123 ORDER BY created_at DESC LIMIT 1;

• 若有索引 (user_id, created_at DESC)：極快，索引下推直接取第一條。
• 若無索引：全表掃描 + 文件排序 + 取第一條，**比無 LIMIT 更慢** (需排序所有匹配行)。

總結

1. LIMIT 1 是**無唯一索引大表單行查詢**的利器，實測可減半耗時。
2. **根治之道是建立唯一索引**，讓優化器在邏輯層面保證單行。
3. 配合 ORDER BY 時，**必須有對應複合索引**，否則得不償失。
4. 代碼審查時，檢查「預期單行查詢是否加 LIMIT 1 / 是否有唯一索引」。