一、基礎(chǔ)核心篇（初級 / 中級必問，重中之重，面試保底分，占比 40%）

1. MySQL 是什么？核心特點有哪些？

答案要點 MySQL 是一款開源的關(guān)系型數(shù)據(jù)庫（RDBMS），基于 SQL 語言，主打輕量、高性能、高可用、易部署，是互聯(lián)網(wǎng)行業(yè)首選的數(shù)據(jù)庫（電商、金融、社交等 90% 以上業(yè)務(wù)都在用）。核心特點：

1. 支持關(guān)系型數(shù)據(jù)庫特性：ACID 事務(wù)、外鍵、約束、多表關(guān)聯(lián)查詢。
2. 高性能：底層優(yōu)化優(yōu)秀，支持海量數(shù)據(jù)存儲，單表千萬級數(shù)據(jù)查詢依然高效。
3. 多存儲引擎：支持插件式引擎，最常用 InnoDB（默認）、MyISAM。
4. 高可用：支持主從復(fù)制、讀寫分離、集群部署，避免單點故障。
5. 跨平臺：支持 Linux/Windows/Mac，適配所有主流服務(wù)器系統(tǒng)。

2. MySQL 中 InnoDB 和 MyISAM 存儲引擎的區(qū)別？（【必考】高頻中的高頻，必須背會）

 ? 核心結(jié)論：MySQL5.5 及以后，默認存儲引擎是 InnoDB，InnoDB 是事務(wù)安全型引擎，MyISAM 是性能型引擎，MyISAM 已被官方逐步淘汰。

3. char 和 varchar 的區(qū)別？varchar (5) 和 varchar (200) 的區(qū)別？（高頻坑點）

 答案要點 二者都是字符串類型，核心區(qū)別是存儲方式和長度固定性，面試必問第二個問題，是經(jīng)典坑點！

一、char 與 varchar 核心區(qū)別

1. char(n)：定長字符串，n 代表固定長度（0-255）。
   • 特點：無論存入多少字符，都會占用 n 個字符的空間，不足補空格；查詢速度極快，適合短字符串、長度固定的場景。
   • 適用：手機號、身份證號、性別、狀態(tài)碼（如 0/1）。
2. varchar(n)：變長字符串，n 代表最大長度（0-65535）。
   • 特點：實際占用空間 = 真實字符長度 + 1/2 個字節(jié)（存儲長度），不會補空格；查詢速度略慢于 char，適合長度不固定的長字符串。
   • 適用：用戶名、商品標題、描述、地址等。

二、面試坑點：varchar(5)和varchar(200)存儲 "abc" 的區(qū)別？

? 標準答案：存儲上無區(qū)別，性能上幾乎無區(qū)別

• 存儲：兩者存入 "abc" 時，實際占用的字節(jié)數(shù)完全相同，都是 3 + 1 個字節(jié)。
• 性能：MySQL 只會校驗「是否超過最大長度」，不會因為定義的長度大而浪費空間 / 變慢。
• 注意：不要無腦定義 varchar(255/65535)，要按需定義，避免字段長度溢出、索引失效。

4. datetime 和 timestamp 的區(qū)別？（高頻考點）

答案要點 二者都是日期時間類型，核心區(qū)別是存儲范圍、時區(qū)支持、占用空間：

1. datetime：占 8 字節(jié)，存儲范圍 1000-01-01 ~ 9999-12-31，不支持時區(qū)轉(zhuǎn)換，存入什么時間就顯示什么時間，不受數(shù)據(jù)庫時區(qū)影響。
2. timestamp：占 4 字節(jié)，存儲范圍 1970-01-01 ~ 2038-01-19，支持時區(qū)轉(zhuǎn)換，存入時會轉(zhuǎn)成 UTC 時間，查詢時按當前時區(qū)轉(zhuǎn)回，占用空間更小。適用場景：業(yè)務(wù)無時區(qū)需求 → 用 datetime；有跨國 / 跨時區(qū)需求 → 用 timestamp；推薦用 datetime，避免 2038 年溢出問題。

5. 主鍵、唯一索引、普通索引、外鍵的區(qū)別？（必考）

核心定義 + 區(qū)別

1. 主鍵索引（Primary Key）
   • 特性：一張表只能有一個主鍵，主鍵字段非空 + 唯一，InnoDB 中主鍵是聚簇索引，數(shù)據(jù)按主鍵排序存儲，查詢效率最高。
   • 作用：唯一標識一條記錄，是表的核心索引。
2. 唯一索引（Unique Key）
   • 特性：一張表可以有多個唯一索引，索引字段唯一但可以為空（最多一個 null）。
   • 作用：保證字段值的唯一性，如手機號、郵箱、用戶名。
3. 普通索引（Index）
   • 特性：一張表可以有多個普通索引，字段值可重復(fù)、可空，無約束性。
   • 作用：單純提升查詢速度，是最常用的索引類型，如商品標題、訂單編號。
4. 外鍵索引（Foreign Key）
   • 特性：建立兩張表的關(guān)聯(lián)關(guān)系，外鍵字段的值必須是另一張表的主鍵值，保證數(shù)據(jù)的參照完整性。
   • 注意：生產(chǎn)環(huán)境慎用外鍵，會降低增刪改效率，一般在業(yè)務(wù)層保證關(guān)聯(lián)完整性即可。

面試加分

• 主鍵可以是唯一索引，唯一索引不一定是主鍵；
• 主鍵字段建議用自增整型（int/bigint），不要用字符串，提升索引效率。

6. 什么是索引？索引的作用？為什么索引能提升查詢速度？

答案要點

索引定義

索引是 MySQL 的一種特殊數(shù)據(jù)結(jié)構(gòu)（B + 樹），建立在表的一個或多個字段上，索引存儲了字段的值和對應(yīng)的行數(shù)據(jù)地址，相當于表的「目錄」。

索引的核心作用

1. 提升查詢速度：通過索引快速定位到數(shù)據(jù)行，避免全表掃描（核心作用）；
2. 加速排序 / 分組：索引本身是有序的，order by/group by 時可直接用索引排序，無需額外排序；
3. 保證數(shù)據(jù)唯一性：主鍵、唯一索引可以約束字段唯一性。

索引提速的本質(zhì)

• 無索引：查詢時是全表掃描，逐行匹配條件，時間復(fù)雜度 O(n)；
• 有索引：通過 B + 樹的有序結(jié)構(gòu)，二分查找定位數(shù)據(jù)，時間復(fù)雜度 O(logn)；
• 類比：查字典時，通過拼音目錄找字，比逐頁翻字典快百倍。

索引的缺點（面試必答，體現(xiàn)思考深度）

索引不是越多越好，有優(yōu)點必有缺點，這是面試加分項：

1. 增刪改變慢：數(shù)據(jù)變更時，需要同步維護索引結(jié)構(gòu)，索引越多，維護成本越高；
2. 占用磁盤空間：索引是獨立的文件，會占用額外的磁盤空間；
3. 過度索引會導致索引失效：不合理的索引會讓 MySQL 優(yōu)化器選擇錯誤的索引。

7. 最左匹配原則是什么？（索引核心考點，必考）

答案要點（必須背會，面試滿分答案）

1. 定義：最左匹配原則是 聯(lián)合索引的核心規(guī)則，當創(chuàng)建(a,b,c)的聯(lián)合索引時，MySQL 會優(yōu)先匹配索引的最左側(cè)字段，并依次向右匹配，跳過的字段會導致索引失效。
2. 核心規(guī)則：
   • 支持：where a=1、where a=1 and b=2、where a=1 and b=2 and c=3 → 全匹配索引；
   • 失效：where b=2、where c=3、where b=2 and c=3 → 跳過了最左的 a，索引完全失效；
   • 部分生效：where a=1 and c=3 → a 字段走索引，c 字段不走索引（中間跳過 b）。
3. 延伸規(guī)則：聯(lián)合索引中，范圍查詢（>、<、like）后的字段會失效。
   • 例如：where a=1 and b>2 and c=3 → a、b 走索引，c 字段失效。

? 面試結(jié)論：創(chuàng)建聯(lián)合索引時，把查詢頻率最高、篩選性最強的字段放在最左側(cè)。

二、進階原理篇（中 / 高級必問，拉開面試差距，核心考點，占比 35%）

1. MySQL 索引的底層數(shù)據(jù)結(jié)構(gòu)是什么？為什么用 B + 樹，不用 B 樹 / 哈希 / 紅黑樹？（【天花板考點】必考，面試分水嶺）

答案要點（標準答案，分點作答，面試滿分）

一、InnoDB 索引的底層結(jié)構(gòu)：B + 樹

• 普通索引：葉子節(jié)點存儲「字段值 + 主鍵值」；
• 主鍵索引（聚簇索引）：葉子節(jié)點存儲「主鍵值 + 整行數(shù)據(jù)」，這是 InnoDB 的核心特性。

二、為什么 MySQL 選擇 B + 樹，不選其他結(jié)構(gòu)？（核心必答，體現(xiàn)原理功底）

? 對比 1：為什么不用【哈希索引】？

        哈希索引是鍵值對映射，查詢效率 O(1)，看似更快，但有致命缺陷，MySQL 僅 Memory 引擎支持：

1. 哈希索引只支持等值查詢（=、in），不支持范圍查詢（>、<、like、between）；
2. 哈希索引是無序的，無法用于排序（order by）；
3. 哈希沖突：哈希值相同的字段會形成鏈表，沖突嚴重時查詢效率暴跌。

? 對比 2：為什么不用【二叉樹 / 紅黑樹】？

1. 二叉樹：極端情況下會退化成單鏈表，查詢效率從O(logn)變成O(n)，完全失效；
2. 紅黑樹：屬于平衡二叉樹，但樹的高度過高，千萬級數(shù)據(jù)時樹高可達幾十層，磁盤 IO 次數(shù)過多（索引在磁盤上，每層對應(yīng)一次 IO）。

? 對比 3：為什么不用【B 樹】，而用 B + 樹？

B 樹和 B + 樹都是多路平衡樹，核心區(qū)別在葉子節(jié)點，B + 樹是 B 樹的優(yōu)化版，完美適配 MySQL 的磁盤存儲，優(yōu)勢有 3 點：

1. B + 樹的非葉子節(jié)點只存索引，不存數(shù)據(jù)：一頁能存更多索引，樹的高度更低，磁盤 IO 次數(shù)更少（MySQL 中一次 IO 對應(yīng)一頁數(shù)據(jù)，樹高越低越快）；
2. B + 樹的葉子節(jié)點是雙向鏈表：支持范圍查詢，這是 B 樹沒有的核心優(yōu)勢（如查詢 id 100-200，B + 樹直接遍歷鏈表即可）；
3. B + 樹的查詢效率穩(wěn)定：所有查詢都要走到葉子節(jié)點，查詢時間固定，B 樹的查詢時間不固定。

? 面試總結(jié)：B + 樹完美適配 MySQL 的「磁盤 IO」和「范圍查詢」兩大核心需求，是最優(yōu)解。

2. MySQL 事務(wù)的四大特性（ACID）？（必考，基礎(chǔ)中的基礎(chǔ)）

答案要點（背誦即可，分點清晰）事務(wù)是數(shù)據(jù)庫中一組不可分割的 SQL 操作，要么全部執(zhí)行成功，要么全部失敗回滾，事務(wù)的核心是四大特性，簡稱 ACID：

1. 原子性（Atomicity）：事務(wù)中的所有操作，是一個整體，要么全成功，要么全回滾，不存在部分執(zhí)行的情況（核心：不可分割）。
   • 例：轉(zhuǎn)賬時，A 扣款、B 加款，要么都成功，要么都失敗。
2. 一致性（Consistency）：事務(wù)執(zhí)行前后，數(shù)據(jù)庫的數(shù)據(jù)完整性、業(yè)務(wù)規(guī)則保持不變（核心：數(shù)據(jù)正確）。
   • 例：轉(zhuǎn)賬前后，A+B 的總金額不變；訂單創(chuàng)建后，庫存數(shù)減少對應(yīng)數(shù)量。
3. 隔離性（Isolation）：多個事務(wù)并發(fā)執(zhí)行時，事務(wù)之間相互隔離，互不影響，每個事務(wù)感覺不到其他事務(wù)的存在（核心：互不干擾）。
   • 隔離性由「事務(wù)隔離級別」和「鎖機制」保證，解決并發(fā)事務(wù)的臟讀、不可重復(fù)讀、幻讀問題。
4. 持久性（Durability）：事務(wù)提交后，修改的數(shù)據(jù)會永久寫入磁盤，即使數(shù)據(jù)庫崩潰重啟，數(shù)據(jù)也不會丟失（核心：永久生效）。
   • 持久性由 MySQL 的redo 日志保證。

3. 并發(fā)事務(wù)會產(chǎn)生哪些問題？MySQL 的事務(wù)隔離級別有哪些？默認是哪個？（【必考】高頻核心，重中之重）

? 核心邏輯：事務(wù)隔離級別就是為了解決并發(fā)事務(wù)的三大問題，隔離級別越高，并發(fā)問題越少，性能越低。

一、并發(fā)事務(wù)的三大問題（按嚴重程度排序）

1. 臟讀：事務(wù) A 讀取到了事務(wù) B未提交的數(shù)據(jù)，之后 B 回滾，A 讀到的數(shù)據(jù)是「臟數(shù)據(jù)」，完全無效。
2. 不可重復(fù)讀：事務(wù) A 中，多次讀取同一數(shù)據(jù)，期間事務(wù) B 修改并提交了該數(shù)據(jù)，導致 A 多次讀取的結(jié)果不一致（針對修改 / 更新操作）。
3. 幻讀：事務(wù) A 中，多次執(zhí)行同一查詢條件的 SQL，期間事務(wù) B 新增 / 刪除了符合條件的數(shù)據(jù)，導致 A 查詢的結(jié)果條數(shù)不一致，像出現(xiàn)了「幻覺」（針對新增 / 刪除操作）。

二、MySQL 的 4 種事務(wù)隔離級別（按隔離強度從低到高排序，必背）

所有隔離級別都基于 SET TRANSACTION ISOLATION LEVEL 級別名 設(shè)置，MySQL 默認隔離級別：可重復(fù)讀（RR），Oracle 默認：讀已提交（RC）。

1. 讀未提交（READ UNCOMMITTED）：最低級別，允許讀取未提交的數(shù)據(jù) → 存在臟讀、不可重復(fù)讀、幻讀，幾乎不用。
2. 讀已提交（READ COMMITTED，RC）：只能讀取其他事務(wù)已提交的數(shù)據(jù) → 解決臟讀，存在不可重復(fù)讀、幻讀。
3. 可重復(fù)讀（REPEATABLE READ，RR）：MySQL默認級別，同一個事務(wù)內(nèi)，多次讀取同一數(shù)據(jù)結(jié)果一致 → 解決臟讀、不可重復(fù)讀，理論存在幻讀，實際被 InnoDB 解決了 ?。
4. 串行化（SERIALIZABLE）：最高級別，事務(wù)串行執(zhí)行，完全禁止并發(fā) → 解決所有問題，但性能極差，適合并發(fā)量極低的場景（如金融對賬）。

面試加分：MySQL 的 RR 級別，為什么能解決幻讀？

        ? 標準答案：InnoDB 在 RR 級別下，通過 「間隙鎖 + 臨鍵鎖」的組合（Next-Key Lock），鎖住了數(shù)據(jù)的「行 + 區(qū)間」，徹底阻止了其他事務(wù)的新增 / 刪除操作，從而解決了幻讀問題。

4. InnoDB 的鎖機制？行鎖、表鎖、樂觀鎖、悲觀鎖的區(qū)別？（必考，核心考點）

一、InnoDB 的兩種核心鎖（按粒度劃分）

InnoDB 是行鎖為主、表鎖為輔的存儲引擎，這也是它并發(fā)性能遠超 MyISAM 的核心原因，鎖的粒度越小，并發(fā)越高。

1. 行級鎖：鎖住表中的某一行數(shù)據(jù)，其他事務(wù)可以操作表中其他行，并發(fā)性能極高。
   • 觸發(fā)條件：必須命中索引，如果查詢沒有走索引，行鎖會升級為表鎖！（經(jīng)典坑點，必答）
   • 分類：共享鎖（S 鎖，讀鎖）、排他鎖（X 鎖，寫鎖），讀鎖之間兼容，讀寫鎖互斥，寫寫鎖互斥。
2. 表級鎖：鎖住整張表，其他事務(wù)無法操作表中的任何數(shù)據(jù)，并發(fā)性能極差。
   • 觸發(fā)條件：無索引查詢、全表掃描、執(zhí)行 alter table 等 DDL 語句時觸發(fā)。

二、樂觀鎖 & 悲觀鎖（按鎖的思想劃分，業(yè)務(wù)開發(fā)必考）

這是業(yè)務(wù)層的鎖機制，不是數(shù)據(jù)庫原生鎖，面試必問，也是生產(chǎn)中解決并發(fā)問題的核心方案，兩者無優(yōu)劣，按需選擇。

1. 悲觀鎖（Pessimistic Lock）

   • 核心思想：悲觀的認為，每次操作都會有并發(fā)沖突，所以在操作數(shù)據(jù)前，先鎖住數(shù)據(jù)，直到操作完成才釋放鎖。
   • 數(shù)據(jù)庫實現(xiàn)：select ... for update（排他鎖），select ... lock in share mode（共享鎖）。
   • 適用場景：寫多讀少的高并發(fā)場景（如庫存扣減、訂單創(chuàng)建、轉(zhuǎn)賬），并發(fā)沖突概率高。
   • 優(yōu)點：簡單粗暴，能保證數(shù)據(jù)一致性；缺點：加鎖會有性能開銷，可能導致死鎖。

2. 樂觀鎖（Optimistic Lock）

   • 核心思想：樂觀的認為，每次操作都不會有并發(fā)沖突，所以操作數(shù)據(jù)時不加鎖，只在提交時判斷數(shù)據(jù)是否被修改過。
   • 實現(xiàn)方式：版本號法（推薦），在表中加version字段，更新時判斷版本號是否一致：update table set name='xxx', version=version+1 where id=1 and version=2。
   • 適用場景：讀多寫少的場景（如商品詳情查詢、用戶信息修改），并發(fā)沖突概率低。
   • 優(yōu)點：無鎖開銷，性能極高；缺點：無法解決 100% 的并發(fā)沖突，沖突時需要業(yè)務(wù)層重試。

        ? 面試結(jié)論：寫多讀少用悲觀鎖，讀多寫少用樂觀鎖，這是生產(chǎn)環(huán)境的最優(yōu)選型。

5. MySQL 三大日志（redo log、undo log、binlog）的區(qū)別和作用？（必考，源碼級考點）

MySQL 的三大日志是保證數(shù)據(jù)安全、事務(wù)一致性、主從復(fù)制的核心，三者缺一不可，面試必問，也是理解 InnoDB 的關(guān)鍵，必須分清楚三者的作用和區(qū)別。

一、redo log 重做日志（InnoDB 獨有，事務(wù)持久性的保證）

1. 核心作用：保證事務(wù)的 持久性（ACID-D），解決「數(shù)據(jù)庫崩潰后數(shù)據(jù)丟失」的問題。
2. 工作原理：InnoDB 是內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)修改先寫入內(nèi)存的 buffer pool，再異步刷盤到磁盤。為了防止內(nèi)存數(shù)據(jù)丟失，每次執(zhí)行寫操作時，都會先把修改記錄寫入 redo log，如果數(shù)據(jù)庫崩潰，重啟后會通過 redo log 恢復(fù)數(shù)據(jù)，保證數(shù)據(jù)不丟失。
3. 特點：物理日志（記錄「哪個頁修改了什么內(nèi)容」）、循環(huán)寫入（固定大小，寫滿覆蓋）、事務(wù)提交時刷盤。

二、undo log 回滾日志（InnoDB 獨有，事務(wù)原子性的保證）

1. 核心作用：保證事務(wù)的 原子性（ACID-A），實現(xiàn)「事務(wù)回滾」和「MVCC 多版本并發(fā)控制」。
2. 工作原理：執(zhí)行寫操作時，InnoDB 會先把「修改前的數(shù)據(jù)」寫入 undo log，當事務(wù)執(zhí)行失敗需要回滾時，通過 undo log 恢復(fù)到修改前的狀態(tài)；同時，undo log 也存儲了數(shù)據(jù)的歷史版本，供 MVCC 讀取。
3. 特點：邏輯日志（記錄「執(zhí)行了什么反向操作」）、可回滾、支持多版本。

三、binlog 歸檔日志（MySQL 服務(wù)器層日志，所有引擎都支持）

1. 核心作用：實現(xiàn) 主從復(fù)制 和 數(shù)據(jù)備份 / 恢復(fù)，是 MySQL 分布式架構(gòu)的核心。
2. 工作原理：記錄所有的DDL 和 DML 語句（建表、增刪改），以二進制形式存儲，主庫的 binlog 會同步到從庫，從庫執(zhí)行 binlog 中的語句，實現(xiàn)主從數(shù)據(jù)一致。
3. 特點：邏輯日志、追加寫入（寫滿新建文件，不覆蓋）、有三種格式（STATEMENT/ROW/MIXED），生產(chǎn)推薦 ROW 格式。

三者核心區(qū)別（面試必答，滿分答案）

1. 歸屬不同：redo/undo 是InnoDB 引擎層日志，binlog 是MySQL 服務(wù)器層日志；
2. 作用不同：redo 保證持久化，undo 保證原子性，binlog 保證主從同步；
3. 寫入方式不同：redo 循環(huán)寫，undo/binlog 追加寫；
4. 內(nèi)容不同：redo 是物理日志，undo/binlog 是邏輯日志。

6. 什么是 MVCC？實現(xiàn)原理是什么？（中高級必考，加分項）

答案要點（精簡版，面試夠用，不啰嗦）

1. 定義：MVCC = 多版本并發(fā)控制，是 InnoDB 在RR 級別下實現(xiàn)的一種無鎖并發(fā)控制機制，核心是「讀不加鎖，讀寫不沖突」，極大提升并發(fā)性能。
2. 核心思想：為每一行數(shù)據(jù)維護多個歷史版本，不同事務(wù)讀取不同版本的數(shù)據(jù)，事務(wù)修改數(shù)據(jù)時，不會覆蓋原數(shù)據(jù)，而是生成新的版本，舊版本通過 undo log 保存。
3. 實現(xiàn)原理：基于 undo log（歷史版本）+ 事務(wù) ID + ReadView（可見性規(guī)則） 實現(xiàn)，簡單說就是：事務(wù)讀取數(shù)據(jù)時，通過 ReadView 判斷哪些版本的數(shù)據(jù)對當前事務(wù)可見，從而讀取到一致的數(shù)據(jù)，無需加鎖。
4. 優(yōu)勢：解決了「讀鎖和寫鎖的互斥問題」，讀操作不用加鎖，寫操作只加行鎖，并發(fā)性能大幅提升。

三、高級優(yōu)化 & 實戰(zhàn)篇（資深 / 架構(gòu)師必問，高薪考點，拔高面試檔次，占比 25%）

1. MySQL 慢查詢優(yōu)化的完整步驟？（【實戰(zhàn)必考】面試壓軸題，背會就是加分）

        ? 核心：面試時回答這個問題，一定要分步驟、有邏輯，體現(xiàn)你有完整的問題排查和優(yōu)化思路，這是企業(yè)最看重的實戰(zhàn)能力！

慢查詢優(yōu)化 6 步黃金法則（必背，生產(chǎn)通用，萬能答案）

步驟 1：開啟慢查詢?nèi)罩荆ㄎ宦?SQL

• 開啟慢查詢：slow_query_log = ON，設(shè)置慢查詢閾值：long_query_time = 1（執(zhí)行時間 > 1 秒的 SQL 為慢查詢）；
• 查看慢查詢?nèi)罩荆?code>show slow logs，或用工具mysqldumpslow分析日志，找到執(zhí)行時間長、掃描行數(shù)多的慢 SQL。

步驟 2：用 EXPLAIN 分析慢 SQL 執(zhí)行計劃（核心）

• 執(zhí)行 EXPLAIN + 慢SQL，查看執(zhí)行計劃的關(guān)鍵字段：type、key、rows、Extra；
• 核心判斷標準：? type：查詢類型，最優(yōu)是const，其次是eq_ref、range、ref，最差是ALL（全表掃描，必須優(yōu)化）；? key：是否命中索引，為NULL表示無索引，需要創(chuàng)建索引；? rows：掃描的行數(shù)，行數(shù)越少越好；? Extra：出現(xiàn)Using filesort（文件排序）、Using temporary（臨時表）、Using index（覆蓋索引）是關(guān)鍵優(yōu)化點。

步驟 3：優(yōu)化索引（最常用、最有效的優(yōu)化手段）

• 針對無索引的慢 SQL：創(chuàng)建合適的索引（主鍵、唯一、普通、聯(lián)合索引）；
• 針對索引失效的 SQL：修復(fù)索引失效問題（見下文考點 2）；
• 針對冗余索引：刪除無用的索引，避免索引過多導致優(yōu)化器選擇錯誤。

步驟 4：優(yōu)化 SQL 語句本身（避坑，核心）

• 避免寫復(fù)雜的多表關(guān)聯(lián)，拆分 SQL；
• 避免使用select *，只查需要的字段，實現(xiàn)「覆蓋索引」；
• 避免使用%xxx模糊查詢（左模糊會導致索引失效）；
• 避免使用in、not in、or，改用exists、union all；
• 大表分頁優(yōu)化：select * from table where id>10000 limit 10 替代 limit 10000,10。

步驟 5：優(yōu)化表結(jié)構(gòu)

• 大表拆分：垂直拆分（按字段）、水平拆分（按數(shù)據(jù)量）；
• 優(yōu)化數(shù)據(jù)類型：用小類型替代大類型（如 tinyint 替代 int，varchar 替代 text）；
• 分表分庫：單表數(shù)據(jù)量超過千萬級時，考慮分庫分表。

步驟 6：優(yōu)化 MySQL 配置參數(shù)

• 調(diào)優(yōu)內(nèi)存相關(guān)參數(shù)：innodb_buffer_pool_size（設(shè)置為物理內(nèi)存的 50%-70%）、join_buffer_size、sort_buffer_size；
• 調(diào)優(yōu)連接相關(guān)參數(shù)：max_connections、wait_timeout；
• 調(diào)優(yōu)日志相關(guān)參數(shù)：innodb_log_file_size、binlog_cache_size。

2. 索引失效的 10 種常見場景 + 解決方案？（高頻坑點，必背）

        ? 核心：索引失效的本質(zhì)是 MySQL 優(yōu)化器認為走索引的效率，不如全表掃描高，所以放棄使用索引，所有失效場景都圍繞這個核心。

索引失效場景（按高頻度排序，前 8 種必考）

1. 查詢條件中使用函數(shù) / 運算：where abs(id)=10、where name like concat('%', 'abc') → 索引失效；? 解決：避免在索引字段上做函數(shù) / 運算，業(yè)務(wù)層處理后再查詢。
2. 左模糊查詢：where name like '%abc' → 索引失效，where name like 'abc%' → 索引生效；? 解決：業(yè)務(wù)上盡量用右模糊，必須左模糊則用全文索引。
3. 聯(lián)合索引不遵循最左匹配原則：跳過最左字段，索引失效；? 解決：按最左匹配原則編寫查詢條件，調(diào)整聯(lián)合索引的字段順序。
4. 查詢條件中使用！= 或 <>：where id != 10 → 索引失效；? 解決：盡量用=替代，必須用則業(yè)務(wù)層過濾。
5. 查詢條件中使用 is null /is not null：索引字段為 null 時，索引失效；? 解決：字段設(shè)置為not null，默認值為空字符串 / 0。
6. 使用 in /not in /or：where id in (1,2,3)、where id=1 or name='abc' → 索引失效；? 解決：小數(shù)據(jù)量 in 可用，大數(shù)據(jù)量用exists替代；or 改用union all。
7. 數(shù)據(jù)分布不均：如性別字段只有 0/1，創(chuàng)建索引后也不會生效（區(qū)分度太低）；? 解決：不創(chuàng)建索引，直接全表掃描。
8. 查詢條件沒有命中索引：行鎖升級為表鎖，索引失效；? 解決：為查詢條件創(chuàng)建合適的索引。
9. 隱式類型轉(zhuǎn)換：如字段是 int 類型，查詢時傳字符串：where id='10' → 索引失效；? 解決：保證查詢條件的類型和字段類型一致。
10. 優(yōu)化器選擇錯誤：MySQL 優(yōu)化器誤判，選擇全表掃描而非索引；? 解決：用force index(索引名)強制走索引。

3. 大表如何優(yōu)化？單表數(shù)據(jù)量多大需要優(yōu)化？（實戰(zhàn)必考）

一、優(yōu)化閾值

• 行業(yè)共識：單表數(shù)據(jù)量超過 1000 萬行 或 表文件超過 10G，查詢性能會急劇下降，必須優(yōu)化；
• 核心原因：索引樹的高度過高，磁盤 IO 次數(shù)增多，查詢變慢。

二、大表優(yōu)化的 6 種方案（按優(yōu)先級排序，生產(chǎn)通用，必背）

? 方案 1：優(yōu)先做「非分表優(yōu)化」（成本最低，見效最快，首選）

1. 加合適的索引：避免全表掃描，這是最基礎(chǔ)的優(yōu)化；
2. 優(yōu)化 SQL：避免select *、避免大表關(guān)聯(lián)、優(yōu)化分頁查詢；
3. 冷熱數(shù)據(jù)分離：將歷史冷數(shù)據(jù)（如 3 年前的訂單）歸檔到歷史表，主表只保留近期熱數(shù)據(jù)；
4. 開啟分區(qū)表：按時間 / 范圍分區(qū)，查詢時只掃描對應(yīng)分區(qū)，如partition by range (id)，對業(yè)務(wù)無侵入。

? 方案 2：分表優(yōu)化（數(shù)據(jù)量過大，必選）

當非分表優(yōu)化無效時，進行分表，分表分為兩種，按需選擇：

1. 垂直分表：按字段拆分，把大表拆成多個小表，如把訂單表拆成「訂單基本信息表」和「訂單詳情表」；
   • 適用：表的字段過多，部分字段查詢頻率低。
2. 水平分表：按數(shù)據(jù)行拆分，把大表拆成多個結(jié)構(gòu)相同的小表，如把訂單表按用戶 ID 哈希拆成 10 張表；
   • 適用：表的行數(shù)過多，超過千萬級。

? 方案 3：分庫分表（終極方案）

當單庫的存儲和性能達到瓶頸時，采用分庫分表，主流中間件：Sharding-JDBC（輕量，推薦）、MyCat；

• 核心規(guī)則：按哈希 / 范圍 / 時間分片，如按用戶 ID 哈希分庫，按訂單時間范圍分表。

4. MySQL 主從復(fù)制的原理？主從延遲的原因和解決辦法？（架構(gòu)必考）

一、主從復(fù)制的核心原理（3 步，必背）

MySQL 主從復(fù)制是異步復(fù)制，核心是基于 binlog 日志實現(xiàn)，架構(gòu)是「一主多從」，主庫寫，從庫讀，實現(xiàn)讀寫分離、負載均衡、數(shù)據(jù)備份，是 MySQL 高可用的基礎(chǔ)：

1. 主庫：主庫執(zhí)行寫操作后，將 SQL 語句寫入binlog日志；
2. 從庫：從庫的 IO 線程連接主庫，讀取主庫的 binlog 日志，寫入本地的relay log中繼日志；
3. 從庫：從庫的 SQL 線程讀取中繼日志，執(zhí)行其中的 SQL 語句，實現(xiàn)主從數(shù)據(jù)一致。

二、主從延遲的原因 + 解決方案（面試必答，生產(chǎn)高頻問題）

? 主從延遲的核心原因

1. 主庫的寫操作并發(fā)量高，binlog 日志生成速度快，從庫的 SQL 線程處理速度跟不上；
2. 從庫的硬件配置比主庫差，CPU / 內(nèi)存 / 磁盤性能不足；
3. 主庫執(zhí)行大事務(wù)（如批量更新、大表導入），導致 binlog 日志量大，從庫執(zhí)行慢；
4. 主從復(fù)制是異步的，天生存在延遲。

? 主從延遲的解決方案（按優(yōu)先級排序，必背）

1. 提升從庫配置：讓從庫的硬件配置和主庫一致，甚至更好；
2. 減少大事務(wù)：拆分大事務(wù)為小事務(wù)，避免一次性執(zhí)行大量 SQL；
3. 半同步復(fù)制：開啟rpl_semi_sync_master，主庫提交事務(wù)后，等待至少一個從庫接收 binlog 后再返回，減少延遲；
4. 并行復(fù)制：從庫開啟多線程并行執(zhí)行 SQL，提升同步速度；
5. 業(yè)務(wù)層優(yōu)化：對實時性要求高的查詢，強制走主庫，非實時查詢走從庫。

5. 什么是死鎖？死鎖的產(chǎn)生原因和解決辦法？（必考）

一、死鎖的定義

死鎖是指兩個或多個事務(wù)，互相持有對方需要的鎖，同時等待對方釋放鎖，導致所有事務(wù)都無法繼續(xù)執(zhí)行，陷入無限等待的狀態(tài)。

• 例：事務(wù) A 鎖住了行 1，等待行 2 的鎖；事務(wù) B 鎖住了行 2，等待行 1 的鎖 → 死鎖。

二、死鎖的產(chǎn)生條件（4 個，缺一不可）

1. 互斥：同一時刻，一個鎖只能被一個事務(wù)持有；
2. 持有并等待：事務(wù)持有一個鎖，同時申請另一個鎖；
3. 不可搶占：鎖只能由持有事務(wù)主動釋放，不能被其他事務(wù)搶占；
4. 循環(huán)等待：事務(wù)之間形成循環(huán)的鎖等待關(guān)系。

三、死鎖的解決辦法（預(yù)防 + 解決，必背）

? 預(yù)防死鎖（首選，成本最低）

1. 統(tǒng)一事務(wù)的加鎖順序：所有事務(wù)都按相同的順序獲取鎖，如先鎖行 1，再鎖行 2，避免循環(huán)等待；
2. 減少鎖的持有時間：事務(wù)盡量短小，快速執(zhí)行完釋放鎖，避免長時間持有鎖；
3. 盡量用行鎖，少用表鎖：行鎖的粒度小，沖突概率低；
4. 避免大事務(wù)：大事務(wù)會持有鎖很長時間，增加死鎖概率。

? 解決死鎖（發(fā)生后處理）

1. MySQL 會自動檢測死鎖，并回滾其中一個事務(wù)（代價最小的那個），釋放鎖；
2. 手動處理：通過show engine innodb status查看死鎖日志，定位死鎖的事務(wù)和 SQL，優(yōu)化業(yè)務(wù)邏輯。

面試加分小技巧（最后必看）

1. MySQL 面試的核心是 「索引 + 事務(wù) + 鎖 + 優(yōu)化」，這四個模塊占比 90%，吃透即可應(yīng)對所有面試；
2. 回答問題時，分點作答，邏輯清晰，比如慢查詢優(yōu)化、索引失效場景，面試官會覺得你基礎(chǔ)扎實、思路清晰；
3. 遇到原理題（如 B + 樹、主從復(fù)制），不用講源碼細節(jié)，講清楚核心流程和優(yōu)勢即可，面試官要的是你的理解能力，不是背誦能力；
4. 所有優(yōu)化類問題，都要遵循「先低成本，后高成本」的原則，比如大表優(yōu)化先做索引和 SQL 優(yōu)化，再做分表分庫。

總結(jié)

到此這篇關(guān)于MySQL高頻面試題完整版的文章就介紹到這了,更多相關(guān)MySQL高頻面試題內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論