MySQL面试重在理解底层逻辑：索引需掌握B+树特性与失效场景；事务要厘清RR级别下MVCC与间隙锁协同防幻读；SQL优化应具备EXPLAIN分析能力；主从复制需理解binlog机制与一致性保障策略。
MySQL 面试高频问题不是考死记硬背，而是看你怎么理解数据存储、查询优化和系统协作的底层逻辑。 掌握以下核心方向，比刷一百道题更有效。
索引原理与失效场景
面试官常问“为什么加了索引却没走？”——关键不在建没建，而在怎么用、怎么设计。
- B+树结构决定了索引适合范围查询和排序，但不支持对索引字段做函数操作（如 WHERE YEAR(create_time) = 2023 会失效）
- 联合索引遵循最左前缀原则：索引 (a, b, c) 可用于 WHERE a=1 AND b=2，但 WHERE b=2 AND c=3 无法使用
- 隐式类型转换会导致索引失效，比如字段是 VARCHAR，但查询写成 WHERE user_id = 123（数字），MySQL 会自动转类型，放弃索引
- 使用 LIKE '%abc' 时，前导通配符让索引失效；LIKE 'abc%' 则可以走索引
事务隔离级别与幻读解决方案
光背四个级别不够，得说清每种级别下“什么现象会发生、为什么发生、MySQL 怎么解决”。
- 可重复读（RR）是 MySQL 默认级别，通过 MVCC + 间隙锁（Gap Lock）防止幻读
- 快照读（普通 SELECT）依赖 MVCC，读的是事务开始时的已提交版本；当前读（SELECT ... FOR UPDATE / UPDATE / DELETE）会加行锁+间隙锁，锁定范围防止新记录插入
- 注意：RR 下“幻读”在严格定义中仍存在（如新增记录后再次 SELECT 不带条件），但 InnoDB 用间隙锁屏蔽了大部分典型场景
- 不要混淆“不可重复读”和“幻读”：前者是同一行数据被其他事务改了，后者是结果集行数变了（新插入或删除）
SQL 优化实战判断点
面试官给你一条慢 SQL，不会要你立刻写出最优解，而是看你有没有排查路径和取舍意识。
- 先看 EXPLAIN：重点关注 type（是否到 index/const）、key（是否命中索引）、rows（扫描行数）、Extra（是否有 Using filesort / Using temporary）
- 避免 SELECT *，尤其大表关联时，只查需要字段能减少 IO 和网络传输
- 分页深翻（LIMIT 10000, 20）性能差，可改用游标分页（记录上一页最大 ID，用 WHERE id > xxx LIMIT 20）
- 小表驱动大表：JOIN 时把结果集小的表放前面（MySQL 会自动优化，但理解逻辑有助于判断执行计划）
主从复制与一致性保障
分布式场景下，数据库不再是单点，得知道数据怎么流动、断了怎么办、读写怎么分。
- 基于 binlog 的异步复制：主库写入后不等从库，存在延迟；半同步复制（semisync）要求至少一个从库确认才返回成功，兼顾可用性与一致性
- 主从延迟常见原因：大事务、从库负载高、网络抖动、单线程回放（MySQL 5.6+ 支持多线程复制，按库或按事务组并行）
- 读写分离不能简单“写主、读从”，需考虑延迟风险。敏感业务（如刚注册就登录）应强制走主库，或引入 GTID + wait_until_sql_thread_after_gtid 等机制校验
- binlog 格式选 ROW 而非 STATEMENT：避免函数、时间类语句在从库执行结果不一致，也方便审计和闪回
