0赞
赞赏
更多好文
在后端开发、数据工程师或运维岗位的面试中,MySQL几乎成了必考项。别被“数据库”三个字吓到——它不是高深的AI技术,而是你每天写SQL、查数据的基础工具。本文精选真实面试中高频出现的问题,附带实用解析,帮你避开“纸上谈兵”的坑。
一、基础题:别让简单问题翻车
Q1:主键(PRIMARY KEY)和唯一键(UNIQUE KEY)有什么区别?
A:主键必须非空且唯一,一张表只能有一个主键;唯一键允许为空(但只能有一个NULL),可有多个。
面试官想看你是否理解“业务逻辑约束”——比如用户ID用主键,邮箱用唯一键(允许为空)。
Q2:SELECT * FROM table WHERE name = '张三' 为什么可能慢?
A:因为*会扫描所有列,如果表很大且只查少量字段,改用SELECT id, name更高效。
真实场景:某电商面试官问“为什么线上查询卡顿”,答出这点能加分。
Q3:CHAR和VARCHAR怎么选?
A:CHAR(n)固定长度(存'abc'占3字节),适合长度固定(如身份证);VARCHAR(n)可变长度(存'abc'占3字节+1字节头),适合长度不一(如姓名)。
避坑提示:别用CHAR(255)存任意文本,浪费空间!
二、进阶题:面试官常挖的“深水区”
Q4:事务的ACID是什么?MySQL如何保证?
A:
- A 原子性:要么全成功,要么全失败(用
ROLLBACK) - C 一致性:数据符合业务规则(如转账余额不能为负)
- I 隔离性:多事务并发不互相干扰(InnoDB用行锁+MVCC)
- D 持久性:提交后数据永久保存(写入redo log)
关键点:面试时提“MVCC”(多版本并发控制)比背书更专业。
Q5:为什么WHERE age > 30可能用不到索引?
A:索引失效场景:
- 函数操作(如
WHERE YEAR(create_time)=2023) - 隐式类型转换(
WHERE id = '123',id是数字类型) - 使用
OR且部分字段无索引
实战建议:用EXPLAIN看执行计划,这是面试官必问的“黄金工具”。
Q6:主从复制中,从库延迟大的原因是什么?
A:常见原因:
- 主库写入量大(如大事务)
- 从库硬件性能弱(CPU/磁盘慢)
- 网络延迟高
面试技巧:答“监控延迟指标+优化从库配置”比单纯列原因更实用。
三、场景题:模拟真实工作场景
Q7:设计一个“用户登录日志”表,需要考虑哪些?
A:
- 字段:
id(主键)、user_id(外键)、login_time(时间戳)、ip(字符串)、device_type(枚举) - 索引:
user_id + login_time(快速查用户登录记录) - 优化:按月分区(
PARTITION BY RANGE (YEAR(login_time)))
面试官想看你是否懂“业务场景驱动设计”,而非堆砌字段。
Q8:慢查询日志(slow log)怎么分析?
A:
- 开启日志:
SET GLOBAL slow_query_log = 'ON'; - 设置阈值:
SET GLOBAL long_query_time = 1;(1秒以上) - 分析工具:用
mysqldumpslow或pt-query-digest
关键点:别只说“看日志”,要提“用EXPLAIN定位具体SQL”。
Q9:如何避免“死锁”?
A:三条黄金原则:
- 事务尽量短(减少锁持有时间)
- 按固定顺序访问表(如先查user表再查order表)
- 避免在事务中处理用户输入(如等待输入时锁住数据)
真实案例:某面试者答“用SELECT ... FOR UPDATE”,但没提顺序,被追问“如果两个事务互等怎么办”,答不上来。
四、避坑指南:面试官最讨厌的错误
| 错误回答 | 正确思路 |
|---|---|
| “索引越多越好” | “索引会增加写入成本,按查询频率建索引” |
“事务用SET AUTOCOMMIT=0” | “业务需事务时用BEGIN,不用时保持AUTOCOMMIT=1” |
“JOIN比子查询快” | “具体看执行计划,JOIN可能慢于子查询(如小表驱动大表)” |
结语:别被“面试题”绑架
MySQL面试不是考背诵,而是看你能否把数据库用在真实场景中。下次面试前,花10分钟做三件事:
- 用
EXPLAIN分析你写过的慢SQL - 重写一个表设计(比如“点赞功能”)
- 用
SHOW PROCESSLIST看当前连接
小贴士:别死记“主键是聚集索引”——InnoDB中主键是聚集索引,但MyISAM不是。面试官更想知道你是否知道不同引擎的差异。
(本文所有问题基于MySQL 8.0,代码可在本地环境直接验证。记住:能写出正确SQL,比背下100道题更值钱。)
