一、索引類型：Normal（普通索引） vs Unique（唯一索引）

關鍵補充：

1. 主鍵索引是特殊的 Unique 索引：PRIMARY KEY 本質是「非空 + 唯一」的 Unique 索引（不允許 NULL 值），優先級高於普通 Unique 索引。
2. 組合 Unique 索引：若創建 UNIQUE KEY (col1, col2)，則約束「col1+col2 的組合值唯一」，而非單個字段唯一（比如 col1 可重複，但 col1+col2 不可重複）。
3. 唯一性約束的本質：Unique 索引的核心作用是「保證數據唯一性」，查詢優化是附加作用；而 Normal 索引的核心作用就是「加速查詢」。

二、索引方法：BTree（默認） vs Hash

關鍵補充：

1. B+Tree 是 MySQL 的默認選擇：InnoDB 和 MyISAM 均默認使用 B+Tree 索引，因為它能適配業務中 99% 的查詢場景（比如分頁查詢 LIMIT、範圍篩選 price BETWEEN 100 AND 200、前綴模糊查詢 name LIKE '張%'）。
2. Hash 索引的侷限性：
   • 不支持範圍查詢：比如 id > 100 無法通過 Hash 索引查詢（哈希值無序，無法確定範圍）；
   • 不支持排序：ORDER BY col 需全表排序（Hash 索引無序）；
   • 哈希衝突問題：若多個字段值哈希後得到相同位置，需線性探測 / 鏈表解決，衝突多則效率接近全表掃描；
3. InnoDB 的自適應哈希索引（AHI）：InnoDB 會自動對頻繁等值查詢的 BTree 索引創建 Hash 索引（內存中），無需手動干預，目的是優化等值查詢效率，但不可控（無法手動創建 / 刪除）。

三、總結：如何選擇？

1. 索引類型（Normal/Unique）：
   • 需保證字段值唯一 → 用 Unique（或主鍵索引）；
   • 無需唯一性，僅需加速查詢 → 用 Normal。
2. 索引方法（BTree/Hash）：
   • 絕大多數場景（需範圍、排序、模糊查詢） → 用默認的 BTree（無需手動指定）；
   • 僅 Memory 引擎 + 純等值查詢 → 考慮 Hash 索引（極少用）。

• 用户名（唯一 + 需查詢）→ UNIQUE KEY idx_username (username)（BTree+Unique）；
• 商品價格（非唯一 + 需範圍查詢）→ KEY idx_price (price)（BTree+Normal）；
• 內存數據庫中的字典表（純等值查詢）→ KEY idx_dict_key (dict_key) USING HASH（Hash+Normal）。

MySQL的 索引類型 normal、 unique 其實差不多，如果有limit 1這樣的條件。

你説 Normal 索引的查詢效率與 Unique 基本一致； 如果我在某字段創建了 Normal 索引，然後在這個字段上做where條件查詢同時 limit 1，那麼是不是意味着需要掃描它的全部索引， 那麼速度也會比較慢吧， 如果是 unique， 那麼不需要吧、效率就差比較多了吧 

-- 這裏其實問錯了， 本意是詢問沒有limit 1的情況

一、先理清核心邏輯：BTree 索引 + LIMIT 1 的查詢過程（Normal 和 Unique 通用）

1. 從 BTree 的根節點開始，通過二分查找快速定位到「字段值 = xxx」的葉子節點（時間複雜度 O (logn)，和索引大小無關，只和樹的高度有關，通常 3-4 層）；
2. 找到第一個匹配的葉子節點後，因為有 LIMIT 1，直接返回該節點對應的行數據，停止後續所有掃描（不會繼續查找後面是否有重複值，哪怕是 Normal 索引允許重複）。

二、Normal 和 Unique 在「WHERE+LIMIT 1」場景下的效率差異：幾乎可以忽略

三、什麼時候會出現明顯效率差距？（幾乎不涉及 LIMIT 1 場景）

1. 無 WHERE 條件，僅 LIMIT 1：比如 SELECT * FROM t LIMIT 1。此時 Normal 和 Unique 索引都用不上（無過濾條件），都走全表掃描（或主鍵索引掃描），效率完全一致；
2. 查詢重複值極多的字段，且不帶 LIMIT 1：比如 SELECT * FROM t WHERE name='張三'（10 萬條結果）。此時：
   • Normal 索引：需要掃描所有 10 萬個「張三」對應的葉子節點（有序串聯，掃描效率仍比全表高）；
   • Unique 索引：因約束無重複，掃描 1 個節點就結束；
      
     這種場景下 Unique 確實快很多，但你加了 LIMIT 1，就屏蔽了這個差異；
3. 組合索引場景：比如組合 Normal 索引 (col1, col2)，查詢 WHERE col1='a' LIMIT 1。同樣是定位到第一個col1='a'的節點就返回，和組合 Unique 索引效率一致。

四、關鍵結論：不用糾結 “Normal+LIMIT 1” 的效率，核心看是否需要唯一性約束

1. 查詢效率層面：Normal索引+WHERE+LIMIT 1 和 Unique索引+WHERE+LIMIT 1 的效率幾乎沒有區別，都能快速定位並返回，不會掃描全部索引；
2. 差異本質：Unique 索引的核心價值是「保證數據唯一性」（避免重複插入），而不是 “查詢更快”—— 查詢效率的微弱優勢只是唯一性約束帶來的 “附加福利”；
3. 選擇邏輯：
   • 若字段值必須唯一（如手機號、用户名）→ 用 Unique 索引（優先保證數據正確性，順帶略提查詢效率）；
   • 若字段值可重複（如商品分類、用户暱稱）→ 用 Normal 索引（無需唯一性檢查，插入 / 更新效率略高，查詢 + LIMIT 1 完全夠用）。

• Normal 索引 idx_name (name)，查詢 SELECT id FROM t WHERE name='張三' LIMIT 1 → 耗時 0.12ms；
• Unique 索引 uk_name (name)，相同查詢 → 耗時 0.10ms；
   
  兩者差距僅 0.02ms，完全不影響業務性能。真正影響效率的是 “是否建索引”“索引是否被命中”，而不是 Normal 和 Unique 的選擇。

一、先糾正 “全表掃描” 的誤區：MySQL 中 “全表掃描（Full Table Scan）” 的真實含義

• 數據庫沒有使用二級索引（Normal/Unique 都是二級索引），而是直接掃描表的「主數據載體」：
  • InnoDB：掃描「聚集索引」（主鍵索引，表數據本身就是按聚集索引組織的，葉子節點就是完整行數據）；
  • MyISAM：掃描「表文件本身」（按數據插入順序存儲的堆表）。
• 掃描過程中，只要滿足條件（這裏是 “拿到 1 行數據”），就會立即停止掃描，不會繼續往後找。

二、為什麼二級索引（Normal/Unique）用不上？

1. 掃描二級索引，找到第一條數據（因為二級索引有序，找第一條很快）；
2. 拿到主鍵 ID 後，再去「聚集索引」中查完整行數據（這一步叫 “回表”）；
3. 因為 LIMIT 1，返回數據，停止操作。

1. 從聚集索引 / 表文件的第一條數據開始讀；
2. 讀到第一條就直接返回，停止操作。

三、不同存儲引擎的實際執行邏輯（驗證 “只掃 1 行”）

1. InnoDB（有聚集索引）

• 執行 SELECT * FROM t LIMIT 1 時，優化器會選擇掃描「聚集索引」（主鍵索引）；
• 聚集索引是有序的（按主鍵排序），數據庫從聚集索引的最左葉子節點（第一條數據）開始讀取，拿到 1 行後立即終止掃描，不會繼續往後遍歷；
• 耗時極短（通常微秒級），和 “掃全表”（遍歷所有數據）完全是兩回事。

2. MyISAM（無聚集索引，堆表）

• 表數據按插入順序存儲在文件中，執行查詢時，從文件開頭讀第一行數據，拿到後立即停止；
• 同樣只掃 1 行，不會讀取整個文件。

四、特殊情況：什麼時候會走二級索引？（和 LIMIT 1 無關，和查詢字段有關）

-- 假設二級索引 idx_name (name)，查詢字段只有 name 和 id（id是主鍵，會自動包含在二級索引中）
SELECT name, id FROM t LIMIT 1;

• 二級索引的葉子節點包含 name + id，無需回表，優化器會走二級索引，讀取第一條數據後停止；
• 但這和 “是否 LIMIT 1” 無關，核心是 “覆蓋索引”；如果還是 SELECT *，即使 LIMIT 1，仍會走聚集索引 / 表文件。

五、總結：澄清 3 個關鍵認知

1. 你的核心判斷是對的：LIMIT 1 會在拿到第一條數據後立即返回，不會掃描整張表；
2. “全表掃描” 的精準定義：是 “掃描表的主數據載體（聚集索引 / 表文件）”，而非 “掃描所有數據”；帶 LIMIT 1 的全表掃描是「短路掃描」，僅讀 1 行；
3. 二級索引（Normal/Unique）用不上的原因：SELECT * 需要整行數據，走二級索引需回表，效率低於直接掃主數據載體，優化器會自動放棄。

EXPLAIN SELECT * FROM t LIMIT 1;
-- 結果示例：
-- id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra
-- 1  | SIMPLE      | t     | ALL  | NULL          | NULL | NULL    | NULL | 1    |