<p><strong>MySQL 面试知识体系不是零散知识点的堆砌，而是一个以「存储结构 → 查询执行 → 并发控制 → 高可用设计」为主线的分层闭环。</strong>掌握它，等于抓住了面试中 80% 的核心问题逻辑。</p>
<H3>一、底层存储与索引机制（决定查询快慢的根本）</H3>
<p>面试高频聚焦：为什么加了索引反而变慢？B+树 vs Hash 索引适用场景？覆盖索引如何避免回表？</p>
<ul>
<li>InnoDB 行格式（Compact/Redundant）影响单页存储行数，间接影响 I/O 效率</li>
<li>B+树索引结构：非叶子节点存键值+指针，叶子节点存完整数据（聚簇索引）或主键值（二级索引），且叶子节点双向链表连接</li>
<li>最左前缀原则本质是 B+树查找路径依赖——<font color="red">无法跳过中间列使用后续列索引</font></li>
<li>联合索引 (a,b,c) 可支撑 a、(a,b)、(a,b,c) 查询，但对 b 单独查询或 (b,c) 无效</li>
<li>索引失效常见情况：对索引列做函数操作（如 WHERE YEAR(create_time)=2023）、隐式类型转换、使用 != / NOT IN / LIKE '%xxx'（前置通配）</li>
</ul>
<H3>二、SQL 解析与执行流程（理解 explain 输出的关键）</H3>
<p>面试必问：type=ALL 一定全表扫描？Extra 中 Using filesort 一定低效？</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/code/9608" title="青辰印刷综合业务管理系统(含网站WEB程序)2.0"><img
src="https://img.php.cn/upload/webcode/000/000/020/175946040310779.jpg" alt="青辰印刷综合业务管理系统(含网站WEB程序)2.0" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/code/9608" title="青辰印刷综合业务管理系统(含网站WEB程序)2.0">青辰印刷综合业务管理系统(含网站WEB程序)2.0</a>
<p>易学易用：友好的系统操作界面，无须具备专业知识，即可熟练的使用系统。功能完善：具备新建、修改、明细、审批、导入、导出、删除、批量、打印等功能。模型开发：自定义表单字段选项零代码二次开发，可无限扩展后台功能模块。 维护方便：基于互联网技术B/S体系结构，实施快速，极大的减少系统升级维护工作。售后保证：专业的技术研发团队，可提供可靠的产品迭代、版本升级和技术支持服务。超低成本：一次投入终身使用、用户不</p>
</div>
<a href="/xiazai/code/9608" title="青辰印刷综合业务管理系统(含网站WEB程序)2.0" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div>
<ul>
<li>执行流程四步：连接器 → 查询缓存（MySQL 8.0 已移除）→ 分析器 → 优化器 → 执行器</li>
<li>EXPLAIN 关键字段含义：<br>
– <strong>type</strong>：system ≈ const > eq_ref > ref > range > index > ALL（ALL 不绝对等于全表扫，可能是走覆盖索引的全索引扫描）<br>
– <strong>key</strong>：实际使用的索引名；<strong>key_len</strong>：索引使用字节数（可推断是否用到联合索引前缀）<br>
– <strong>Extra</strong>：Using index（覆盖索引）、Using where（索引下推 ICP 生效）、Using temporary（需临时表，如 GROUP BY 非索引列）、Using filesort（未按索引顺序排序，不等于一定慢，但需警惕）</li>
<li>索引下推（ICP）：5.6+ 支持，将 WHERE 条件部分下推到存储引擎层过滤，减少回表次数</li>
</ul>
<H3>三、事务与锁机制（并发安全的核心防线）</H3>
<p>面试深挖：RR 级别真的完全解决幻读？Gap Lock 为何只在唯一索引范围查询时“失效”？</p>
<ul>
<li>ACID 实现依托：<br>
– 原子性：undo log<br>
– 一致性：业务逻辑 + 原子性 + 隔离性 + 持久性共同保证<br>
– 隔离性：MVCC + 锁（行锁/间隙锁/临键锁）<br>
– 持久性：redo log（WAL 机制）</li>
<li>RR 级别通过 MVCC 解决快照读幻读，但当前读（SELECT ... FOR UPDATE / LOCK IN SHARE MODE）仍可能被新插入记录影响，需临键锁（Gap Lock + Record Lock）阻止</li>
<li>锁类型判断口诀：<br>
– 主键等值查询 → 记录锁（Record Lock）<br>
– 主键范围查询 → 临键锁（Next-Key Lock）<br>
– 非唯一索引等值查询 → 临键锁（会锁住右侧间隙）<br>
– 无索引查询 → 表锁（锁全表）</li>
<li>死锁检测依赖 wait-for graph，InnoDB 自动回滚事务权重小者（undo log 小的）</li>
</ul>
<H3>四、高可用与性能优化（生产落地能力体现）</H3>
<p>面试实战题常考：主从延迟怎么查？分库分表后 count(*) 怎么准？慢 SQL 如何系统治理？</p>
<ul>
<li>主从复制原理：binlog（row 格式为主）→ relay log → SQL Thread 回放；延迟排查看 Seconds_Behind_Master + relay_log_space + 网络/大事务/从库负载</li>
<li>读写分离注意点：强制走主库（如刚写入立即读）、从库延迟容忍策略（业务降级 or 过期读）、GTID 简化故障切换</li>
<li>分库分表常见方案：<br>
– 垂直拆分：按业务模块切库<br>
– 水平拆分：sharding-jdbc / MyCat / DTX（如订单按 user_id hash）<br>
– 跨库分页：全局唯一 ID + 二次查询 or ES 辅助</li>
<li>慢 SQL 治理路径：slow_query_log 开启 → pt-query-digest 分析 → EXPLAIN 定位 → 添加索引 / 重写 SQL / 拆分复杂查询 / 引入缓存</li>
</ul>
