MySQL高频面试题完整版：由浅到深 面试必背

作者：袖梨 2026-07-05

一、基础核心篇（初级 / 中级必问，重中之重，面试保底分，占比 40%）

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

答案要点 MySQL 是一款开源的关系型数据库（RDBMS），基于 SQL 语言，主打轻量、高性能、高可用、易部署，是互联网行业首选的数据库（电商、金融、社交等 90% 以上业务都在用）。核心特点：

MySQL高频面试题完整版(由浅到深,面试必背)

  1. 支持关系型数据库特性：ACID 事务、外键、约束、多表关联查询。
  2. 高性能：底层优化优秀，支持海量数据存储，单表千万级数据查询依然高效。
  3. 多存储引擎：支持插件式引擎，最常用 InnoDB（默认）、MyISAM。
  4. 高可用：支持主从复制、读写分离、集群部署，避免单点故障。
  5. 跨平台：支持 Linux/Windows/Mac，适配所有主流服务器系统。

2. MySQL 中 InnoDB 和 MyISAM 存储引擎的区别？（【必考】高频中的高频，必须背会）

 ✅ 核心结论：MySQL5.5 及以后，默认存储引擎是 InnoDB，InnoDB 是事务安全型引擎，MyISAM 是性能型引擎，MyISAM 已被官方逐步淘汰。

3. char 和 varchar 的区别？varchar (5) 和 varchar (200) 的区别？（高频坑点）

 答案要点 二者都是字符串类型，核心区别是存储方式和长度固定性，面试必问第二个问题，是经典坑点！

一、char 与 varchar 核心区别

  1. char(n)：定长字符串，n 代表固定长度（0-255）。
    • 特点：无论存入多少字符，都会占用 n 个字符的空间，不足补空格；查询速度极快，适合短字符串、长度固定的场景。
    • 适用：手机号、身份证号、性别、状态码（如 0/1）。
  2. varchar(n)：变长字符串，n 代表最大长度（0-65535）。
    • 特点：实际占用空间 = 真实字符长度 + 1/2 个字节（存储长度），不会补空格；查询速度略慢于 char，适合长度不固定的长字符串。
    • 适用：用户名、商品标题、描述、地址等。

二、面试坑点：varchar(5)和varchar(200)存储 "abc" 的区别？

✅ 标准答案：存储上无区别，性能上几乎无区别

  • 存储：两者存入 "abc" 时，实际占用的字节数完全相同，都是 3 + 1 个字节。
  • 性能：MySQL 只会校验「是否超过最大长度」，不会因为定义的长度大而浪费空间 / 变慢。
  • 注意：不要无脑定义 varchar(255/65535)，要按需定义，避免字段长度溢出、索引失效。

4. datetime 和 timestamp 的区别？（高频考点）

答案要点 二者都是日期时间类型，核心区别是存储范围、时区支持、占用空间：

  1. datetime：占 8 字节，存储范围 1000-01-01 ~ 9999-12-31，不支持时区转换，存入什么时间就显示什么时间，不受数据库时区影响。
  2. timestamp：占 4 字节，存储范围 1970-01-01 ~ 2038-01-19，支持时区转换，存入时会转成 UTC 时间，查询时按当前时区转回，占用空间更小。适用场景：业务无时区需求 → 用 datetime；有跨国 / 跨时区需求 → 用 timestamp；推荐用 datetime，避免 2038 年溢出问题。

5. 主键、唯一索引、普通索引、外键的区别？（必考）

核心定义 + 区别

  1. 主键索引（Primary Key）
    • 特性：一张表只能有一个主键，主键字段非空 + 唯一，InnoDB 中主键是聚簇索引，数据按主键排序存储，查询效率最高。
    • 作用：唯一标识一条记录，是表的核心索引。
  2. 唯一索引（Unique Key）
    • 特性：一张表可以有多个唯一索引，索引字段唯一但可以为空（最多一个 null）。
    • 作用：保证字段值的唯一性，如手机号、邮箱、用户名。
  3. 普通索引（Index）
    • 特性：一张表可以有多个普通索引，字段值可重复、可空，无约束性。
    • 作用：单纯提升查询速度，是最常用的索引类型，如商品标题、订单编号。
  4. 外键索引（Foreign Key）
    • 特性：建立两张表的关联关系，外键字段的值必须是另一张表的主键值，保证数据的参照完整性。
    • 注意：生产环境慎用外键，会降低增删改效率，一般在业务层保证关联完整性即可。

面试加分

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

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

答案要点

索引定义

索引是 MySQL 的一种特殊数据结构（B + 树），建立在表的一个或多个字段上，索引存储了字段的值和对应的行数据地址，相当于表的「目录」。

索引的核心作用

  1. 提升查询速度：通过索引快速定位到数据行，避免全表扫描（核心作用）；
  2. 加速排序 / 分组：索引本身是有序的，order by/group by 时可直接用索引排序，无需额外排序；
  3. 保证数据唯一性：主键、唯一索引可以约束字段唯一性。

索引提速的本质

  • 无索引：查询时是全表扫描，逐行匹配条件，时间复杂度 O(n)；
  • 有索引：通过 B + 树的有序结构，二分查找定位数据，时间复杂度 O(logn)；
  • 类比：查字典时，通过拼音目录找字，比逐页翻字典快百倍。

索引的缺点（面试必答，体现思考深度）

索引不是越多越好，有优点必有缺点，这是面试加分项：

  1. 增删改变慢：数据变更时，需要同步维护索引结构，索引越多，维护成本越高；
  2. 占用磁盘空间：索引是独立的文件，会占用额外的磁盘空间；
  3. 过度索引会导致索引失效：不合理的索引会让 MySQL 优化器选择错误的索引。

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

答案要点（必须背会，面试满分答案）

  1. 定义：最左匹配原则是 联合索引的核心规则，当创建(a,b,c)的联合索引时，MySQL 会优先匹配索引的最左侧字段，并依次向右匹配，跳过的字段会导致索引失效。
  2. 核心规则：
    • 支持：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. 延伸规则：联合索引中，范围查询（>、<、like）后的字段会失效。
    • 例如：where a=1 and b>2 and c=3 → a、b 走索引，c 字段失效。

✅ 面试结论：创建联合索引时，把查询频率最高、筛选性最强的字段放在最左侧。

二、进阶原理篇（中 / 高级必问，拉开面试差距，核心考点，占比 35%）

1. MySQL 索引的底层数据结构是什么？为什么用 B + 树，不用 B 树 / 哈希 / 红黑树？（【天花板考点】必考，面试分水岭）

答案要点（标准答案，分点作答，面试满分）

一、InnoDB 索引的底层结构：B + 树

  • 普通索引：叶子节点存储「字段值 + 主键值」；
  • 主键索引（聚簇索引）：叶子节点存储「主键值 + 整行数据」，这是 InnoDB 的核心特性。

二、为什么 MySQL 选择 B + 树，不选其他结构？（核心必答，体现原理功底）

✅ 对比 1：为什么不用【哈希索引】？

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

  1. 哈希索引只支持等值查询（=、in），不支持范围查询（>、<、like、between）；
  2. 哈希索引是无序的，无法用于排序（order by）；
  3. 哈希冲突：哈希值相同的字段会形成链表，冲突严重时查询效率暴跌。

✅ 对比 2：为什么不用【二叉树 / 红黑树】？

  1. 二叉树：极端情况下会退化成单链表，查询效率从O(logn)变成O(n)，完全失效；
  2. 红黑树：属于平衡二叉树，但树的高度过高，千万级数据时树高可达几十层，磁盘 IO 次数过多（索引在磁盘上，每层对应一次 IO）。

✅ 对比 3：为什么不用【B 树】，而用 B + 树？

B 树和 B + 树都是多路平衡树，核心区别在叶子节点，B + 树是 B 树的优化版，完美适配 MySQL 的磁盘存储，优势有 3 点：

  1. B + 树的非叶子节点只存索引，不存数据：一页能存更多索引，树的高度更低，磁盘 IO 次数更少（MySQL 中一次 IO 对应一页数据，树高越低越快）；
  2. B + 树的叶子节点是双向链表：支持范围查询，这是 B 树没有的核心优势（如查询 id 100-200，B + 树直接遍历链表即可）；
  3. B + 树的查询效率稳定：所有查询都要走到叶子节点，查询时间固定，B 树的查询时间不固定。

✅ 面试总结：B + 树完美适配 MySQL 的「磁盘 IO」和「范围查询」两大核心需求，是最优解。

2. MySQL 事务的四大特性（ACID）？（必考，基础中的基础）

答案要点（背诵即可，分点清晰）事务是数据库中一组不可分割的 SQL 操作，要么全部执行成功，要么全部失败回滚，事务的核心是四大特性，简称 ACID：

  1. 原子性（Atomicity）：事务中的所有操作，是一个整体，要么全成功，要么全回滚，不存在部分执行的情况（核心：不可分割）。
    • 例：转账时，A 扣款、B 加款，要么都成功，要么都失败。
  2. 一致性（Consistency）：事务执行前后，数据库的数据完整性、业务规则保持不变（核心：数据正确）。
    • 例：转账前后，A+B 的总金额不变；订单创建后，库存数减少对应数量。
  3. 隔离性（Isolation）：多个事务并发执行时，事务之间相互隔离，互不影响，每个事务感觉不到其他事务的存在（核心：互不干扰）。
    • 隔离性由「事务隔离级别」和「锁机制」保证，解决并发事务的脏读、不可重复读、幻读问题。
  4. 持久性（Durability）：事务提交后，修改的数据会永久写入磁盘，即使数据库崩溃重启，数据也不会丢失（核心：永久生效）。
    • 持久性由 MySQL 的redo 日志保证。

3. 并发事务会产生哪些问题？MySQL 的事务隔离级别有哪些？默认是哪个？（【必考】高频核心，重中之重）

✅ 核心逻辑：事务隔离级别就是为了解决并发事务的三大问题，隔离级别越高，并发问题越少，性能越低。

一、并发事务的三大问题（按严重程度排序）

  1. 脏读：事务 A 读取到了事务 B未提交的数据，之后 B 回滚，A 读到的数据是「脏数据」，完全无效。
  2. 不可重复读：事务 A 中，多次读取同一数据，期间事务 B 修改并提交了该数据，导致 A 多次读取的结果不一致（针对修改 / 更新操作）。
  3. 幻读：事务 A 中，多次执行同一查询条件的 SQL，期间事务 B 新增 / 删除了符合条件的数据，导致 A 查询的结果条数不一致，像出现了「幻觉」（针对新增 / 删除操作）。

二、MySQL 的 4 种事务隔离级别（按隔离强度从低到高排序，必背）

所有隔离级别都基于 SET TRANSACTION ISOLATION LEVEL 级别名 设置，MySQL 默认隔离级别：可重复读（RR），Oracle 默认：读已提交（RC）。

  1. 读未提交（READ UNCOMMITTED）：最低级别，允许读取未提交的数据 → 存在脏读、不可重复读、幻读，几乎不用。
  2. 读已提交（READ COMMITTED，RC）：只能读取其他事务已提交的数据 → 解决脏读，存在不可重复读、幻读。
  3. 可重复读（REPEATABLE READ，RR）：MySQL默认级别，同一个事务内，多次读取同一数据结果一致 → 解决脏读、不可重复读，理论存在幻读，实际被 InnoDB 解决了 ✅。
  4. 串行化（SERIALIZABLE）：最高级别，事务串行执行，完全禁止并发 → 解决所有问题，但性能极差，适合并发量极低的场景（如金融对账）。

面试加分：MySQL 的 RR 级别，为什么能解决幻读？

        ✅ 标准答案：InnoDB 在 RR 级别下，通过 「间隙锁 + 临键锁」的组合（Next-Key Lock），锁住了数据的「行 + 区间」，彻底阻止了其他事务的新增 / 删除操作，从而解决了幻读问题。

4. InnoDB 的锁机制？行锁、表锁、乐观锁、悲观锁的区别？（必考，核心考点）

一、InnoDB 的两种核心锁（按粒度划分）

InnoDB 是行锁为主、表锁为辅的存储引擎，这也是它并发性能远超 MyISAM 的核心原因，锁的粒度越小，并发越高。

  1. 行级锁：锁住表中的某一行数据，其他事务可以操作表中其他行，并发性能极高。
    • 触发条件：必须命中索引，如果查询没有走索引，行锁会升级为表锁！（经典坑点，必答）
    • 分类：共享锁（S 锁，读锁）、排他锁（X 锁，写锁），读锁之间兼容，读写锁互斥，写写锁互斥。
  2. 表级锁：锁住整张表，其他事务无法操作表中的任何数据，并发性能极差。
    • 触发条件：无索引查询、全表扫描、执行 alter table 等 DDL 语句时触发。

二、乐观锁 & 悲观锁（按锁的思想划分，业务开发必考）

这是业务层的锁机制，不是数据库原生锁，面试必问，也是生产中解决并发问题的核心方案，两者无优劣，按需选择。

  1. 悲观锁（Pessimistic Lock）

    • 核心思想：悲观的认为，每次操作都会有并发冲突，所以在操作数据前，先锁住数据，直到操作完成才释放锁。
    • 数据库实现：select ... for update（排他锁），select ... lock in share mode（共享锁）。
    • 适用场景：写多读少的高并发场景（如库存扣减、订单创建、转账），并发冲突概率高。
    • 优点：简单粗暴，能保证数据一致性；缺点：加锁会有性能开销，可能导致死锁。

  2. 乐观锁（Optimistic Lock）

    • 核心思想：乐观的认为，每次操作都不会有并发冲突，所以操作数据时不加锁，只在提交时判断数据是否被修改过。
    • 实现方式：版本号法（推荐），在表中加version字段，更新时判断版本号是否一致：update table set name='xxx', version=version+1 where id=1 and version=2。
    • 适用场景：读多写少的场景（如商品详情查询、用户信息修改），并发冲突概率低。
    • 优点：无锁开销，性能极高；缺点：无法解决 100% 的并发冲突，冲突时需要业务层重试。

        ✅ 面试结论：写多读少用悲观锁，读多写少用乐观锁，这是生产环境的最优选型。

5. MySQL 三大日志（redo log、undo log、binlog）的区别和作用？（必考，源码级考点）

MySQL 的三大日志是保证数据安全、事务一致性、主从复制的核心，三者缺一不可，面试必问，也是理解 InnoDB 的关键，必须分清楚三者的作用和区别。

一、redo log 重做日志（InnoDB 独有，事务持久性的保证）

  1. 核心作用：保证事务的 持久性（ACID-D），解决「数据库崩溃后数据丢失」的问题。
  2. 工作原理：InnoDB 是内存数据库，数据修改先写入内存的 buffer pool，再异步刷盘到磁盘。为了防止内存数据丢失，每次执行写操作时，都会先把修改记录写入 redo log，如果数据库崩溃，重启后会通过 redo log 恢复数据，保证数据不丢失。
  3. 特点：物理日志（记录「哪个页修改了什么内容」）、循环写入（固定大小，写满覆盖）、事务提交时刷盘。

二、undo log 回滚日志（InnoDB 独有，事务原子性的保证）

  1. 核心作用：保证事务的 原子性（ACID-A），实现「事务回滚」和「MVCC 多版本并发控制」。
  2. 工作原理：执行写操作时，InnoDB 会先把「修改前的数据」写入 undo log，当事务执行失败需要回滚时，通过 undo log 恢复到修改前的状态；同时，undo log 也存储了数据的历史版本，供 MVCC 读取。
  3. 特点：逻辑日志（记录「执行了什么反向操作」）、可回滚、支持多版本。

三、binlog 归档日志（MySQL 服务器层日志，所有引擎都支持）

  1. 核心作用：实现 主从复制 和 数据备份 / 恢复，是 MySQL 分布式架构的核心。
  2. 工作原理：记录所有的DDL 和 DML 语句（建表、增删改），以二进制形式存储，主库的 binlog 会同步到从库，从库执行 binlog 中的语句，实现主从数据一致。
  3. 特点：逻辑日志、追加写入（写满新建文件，不覆盖）、有三种格式（STATEMENT/ROW/MIXED），生产推荐 ROW 格式。

三者核心区别（面试必答，满分答案）

  1. 归属不同：redo/undo 是InnoDB 引擎层日志，binlog 是MySQL 服务器层日志；
  2. 作用不同：redo 保证持久化，undo 保证原子性，binlog 保证主从同步；
  3. 写入方式不同：redo 循环写，undo/binlog 追加写；
  4. 内容不同：redo 是物理日志，undo/binlog 是逻辑日志。

6. 什么是 MVCC？实现原理是什么？（中高级必考，加分项）

答案要点（精简版，面试够用，不啰嗦）

  1. 定义：MVCC = 多版本并发控制，是 InnoDB 在RR 级别下实现的一种无锁并发控制机制，核心是「读不加锁，读写不冲突」，极大提升并发性能。
  2. 核心思想：为每一行数据维护多个历史版本，不同事务读取不同版本的数据，事务修改数据时，不会覆盖原数据，而是生成新的版本，旧版本通过 undo log 保存。
  3. 实现原理：基于 undo log（历史版本）+ 事务 ID + ReadView（可见性规则） 实现，简单说就是：事务读取数据时，通过 ReadView 判断哪些版本的数据对当前事务可见，从而读取到一致的数据，无需加锁。
  4. 优势：解决了「读锁和写锁的互斥问题」，读操作不用加锁，写操作只加行锁，并发性能大幅提升。

三、高级优化 & 实战篇（资深 / 架构师必问，高薪考点，拔高面试档次，占比 25%）

1. MySQL 慢查询优化的完整步骤？（【实战必考】面试压轴题，背会就是加分）

        ✅ 核心：面试时回答这个问题，一定要分步骤、有逻辑，体现你有完整的问题排查和优化思路，这是企业最看重的实战能力！

慢查询优化 6 步黄金法则（必背，生产通用，万能答案）

步骤 1：开启慢查询日志，定位慢 SQL

  • 开启慢查询：slow_query_log = ON，设置慢查询阈值：long_query_time = 1（执行时间 > 1 秒的 SQL 为慢查询）；
  • 查看慢查询日志：show slow logs，或用工具mysqldumpslow分析日志，找到执行时间长、扫描行数多的慢 SQL。

步骤 2：用 EXPLAIN 分析慢 SQL 执行计划（核心）

  • 执行 EXPLAIN + 慢SQL，查看执行计划的关键字段：type、key、rows、Extra；
  • 核心判断标准：✔ type：查询类型，最优是const，其次是eq_ref、range、ref，最差是ALL（全表扫描，必须优化）；✔ key：是否命中索引，为NULL表示无索引，需要创建索引；✔ rows：扫描的行数，行数越少越好；✔ Extra：出现Using filesort（文件排序）、Using temporary（临时表）、Using index（覆盖索引）是关键优化点。

步骤 3：优化索引（最常用、最有效的优化手段）

  • 针对无索引的慢 SQL：创建合适的索引（主键、唯一、普通、联合索引）；
  • 针对索引失效的 SQL：修复索引失效问题（见下文考点 2）；
  • 针对冗余索引：删除无用的索引，避免索引过多导致优化器选择错误。

步骤 4：优化 SQL 语句本身（避坑，核心）

  • 避免写复杂的多表关联，拆分 SQL；
  • 避免使用select *，只查需要的字段，实现「覆盖索引」；
  • 避免使用%xxx模糊查询（左模糊会导致索引失效）；
  • 避免使用in、not in、or，改用exists、union all；
  • 大表分页优化：select * from table where id>10000 limit 10 替代 limit 10000,10。

步骤 5：优化表结构

  • 大表拆分：垂直拆分（按字段）、水平拆分（按数据量）；
  • 优化数据类型：用小类型替代大类型（如 tinyint 替代 int，varchar 替代 text）；
  • 分表分库：单表数据量超过千万级时，考虑分库分表。

步骤 6：优化 MySQL 配置参数

  • 调优内存相关参数：innodb_buffer_pool_size（设置为物理内存的 50%-70%）、join_buffer_size、sort_buffer_size；
  • 调优连接相关参数：max_connections、wait_timeout；
  • 调优日志相关参数：innodb_log_file_size、binlog_cache_size。

2. 索引失效的 10 种常见场景 + 解决方案？（高频坑点，必背）

        ✅ 核心：索引失效的本质是 MySQL 优化器认为走索引的效率，不如全表扫描高，所以放弃使用索引，所有失效场景都围绕这个核心。

索引失效场景（按高频度排序，前 8 种必考）

  1. 查询条件中使用函数 / 运算：where abs(id)=10、where name like concat('%', 'abc') → 索引失效；✔ 解决：避免在索引字段上做函数 / 运算，业务层处理后再查询。
  2. 左模糊查询：where name like '%abc' → 索引失效，where name like 'abc%' → 索引生效；✔ 解决：业务上尽量用右模糊，必须左模糊则用全文索引。
  3. 联合索引不遵循最左匹配原则：跳过最左字段，索引失效；✔ 解决：按最左匹配原则编写查询条件，调整联合索引的字段顺序。
  4. 查询条件中使用！= 或 <>：where id != 10 → 索引失效；✔ 解决：尽量用=替代，必须用则业务层过滤。
  5. 查询条件中使用 is null /is not null：索引字段为 null 时，索引失效；✔ 解决：字段设置为not null，默认值为空字符串 / 0。
  6. 使用 in /not in /or：where id in (1,2,3)、where id=1 or name='abc' → 索引失效；✔ 解决：小数据量 in 可用，大数据量用exists替代；or 改用union all。
  7. 数据分布不均：如性别字段只有 0/1，创建索引后也不会生效（区分度太低）；✔ 解决：不创建索引，直接全表扫描。
  8. 查询条件没有命中索引：行锁升级为表锁，索引失效；✔ 解决：为查询条件创建合适的索引。
  9. 隐式类型转换：如字段是 int 类型，查询时传字符串：where id='10' → 索引失效；✔ 解决：保证查询条件的类型和字段类型一致。
  10. 优化器选择错误：MySQL 优化器误判，选择全表扫描而非索引；✔ 解决：用force index(索引名)强制走索引。

3. 大表如何优化？单表数据量多大需要优化？（实战必考）

一、优化阈值

  • 行业共识：单表数据量超过 1000 万行 或 表文件超过 10G，查询性能会急剧下降，必须优化；
  • 核心原因：索引树的高度过高，磁盘 IO 次数增多，查询变慢。

二、大表优化的 6 种方案（按优先级排序，生产通用，必背）

✅ 方案 1：优先做「非分表优化」（成本最低，见效最快，首选）

  1. 加合适的索引：避免全表扫描，这是最基础的优化；
  2. 优化 SQL：避免select *、避免大表关联、优化分页查询；
  3. 冷热数据分离：将历史冷数据（如 3 年前的订单）归档到历史表，主表只保留近期热数据；
  4. 开启分区表：按时间 / 范围分区，查询时只扫描对应分区，如partition by range (id)，对业务无侵入。

✅ 方案 2：分表优化（数据量过大，必选）

当非分表优化无效时，进行分表，分表分为两种，按需选择：

  1. 垂直分表：按字段拆分，把大表拆成多个小表，如把订单表拆成「订单基本信息表」和「订单详情表」；
    • 适用：表的字段过多，部分字段查询频率低。
  2. 水平分表：按数据行拆分，把大表拆成多个结构相同的小表，如把订单表按用户 ID 哈希拆成 10 张表；
    • 适用：表的行数过多，超过千万级。

✅ 方案 3：分库分表（终极方案）

当单库的存储和性能达到瓶颈时，采用分库分表，主流中间件：Sharding-JDBC（轻量，推荐）、MyCat；

  • 核心规则：按哈希 / 范围 / 时间分片，如按用户 ID 哈希分库，按订单时间范围分表。

4. MySQL 主从复制的原理？主从延迟的原因和解决办法？（架构必考）

一、主从复制的核心原理（3 步，必背）

MySQL 主从复制是异步复制，核心是基于 binlog 日志实现，架构是「一主多从」，主库写，从库读，实现读写分离、负载均衡、数据备份，是 MySQL 高可用的基础：

  1. 主库：主库执行写操作后，将 SQL 语句写入binlog日志；
  2. 从库：从库的 IO 线程连接主库，读取主库的 binlog 日志，写入本地的relay log中继日志；
  3. 从库：从库的 SQL 线程读取中继日志，执行其中的 SQL 语句，实现主从数据一致。

二、主从延迟的原因 + 解决方案（面试必答，生产高频问题）

✅ 主从延迟的核心原因

  1. 主库的写操作并发量高，binlog 日志生成速度快，从库的 SQL 线程处理速度跟不上；
  2. 从库的硬件配置比主库差，CPU / 内存 / 磁盘性能不足；
  3. 主库执行大事务（如批量更新、大表导入），导致 binlog 日志量大，从库执行慢；
  4. 主从复制是异步的，天生存在延迟。

✅ 主从延迟的解决方案（按优先级排序，必背）

  1. 提升从库配置：让从库的硬件配置和主库一致，甚至更好；
  2. 减少大事务：拆分大事务为小事务，避免一次性执行大量 SQL；
  3. 半同步复制：开启rpl_semi_sync_master，主库提交事务后，等待至少一个从库接收 binlog 后再返回，减少延迟；
  4. 并行复制：从库开启多线程并行执行 SQL，提升同步速度；
  5. 业务层优化：对实时性要求高的查询，强制走主库，非实时查询走从库。

5. 什么是死锁？死锁的产生原因和解决办法？（必考）

一、死锁的定义

死锁是指两个或多个事务，互相持有对方需要的锁，同时等待对方释放锁，导致所有事务都无法继续执行，陷入无限等待的状态。

  • 例：事务 A 锁住了行 1，等待行 2 的锁；事务 B 锁住了行 2，等待行 1 的锁 → 死锁。

二、死锁的产生条件（4 个，缺一不可）

  1. 互斥：同一时刻，一个锁只能被一个事务持有；
  2. 持有并等待：事务持有一个锁，同时申请另一个锁；
  3. 不可抢占：锁只能由持有事务主动释放，不能被其他事务抢占；
  4. 循环等待：事务之间形成循环的锁等待关系。

三、死锁的解决办法（预防 + 解决，必背）

✅ 预防死锁（首选，成本最低）

  1. 统一事务的加锁顺序：所有事务都按相同的顺序获取锁，如先锁行 1，再锁行 2，避免循环等待；
  2. 减少锁的持有时间：事务尽量短小，快速执行完释放锁，避免长时间持有锁；
  3. 尽量用行锁，少用表锁：行锁的粒度小，冲突概率低；
  4. 避免大事务：大事务会持有锁很长时间，增加死锁概率。

✅ 解决死锁（发生后处理）

  1. MySQL 会自动检测死锁，并回滚其中一个事务（代价最小的那个），释放锁；
  2. 手动处理：通过show engine innodb status查看死锁日志，定位死锁的事务和 SQL，优化业务逻辑。

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

  1. MySQL 面试的核心是 「索引 + 事务 + 锁 + 优化」，这四个模块占比 90%，吃透即可应对所有面试；
  2. 回答问题时，分点作答，逻辑清晰，比如慢查询优化、索引失效场景，面试官会觉得你基础扎实、思路清晰；
  3. 遇到原理题（如 B + 树、主从复制），不用讲源码细节，讲清楚核心流程和优势即可，面试官要的是你的理解能力，不是背诵能力；
  4. 所有优化类问题，都要遵循「先低成本，后高成本」的原则，比如大表优化先做索引和 SQL 优化，再做分表分库。

总结

相关文章

精彩推荐