一、SQL语句篇(高频考点)
- SELECT执行顺序大揭秘(必考!)
当面试官问"SELECT语句的执行顺序"时,建议边画流程图边解释:
FROM → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT
举个真实案例:某次我优化慢查询时,发现WHERE条件中的函数导致索引失效,就是因为没搞清楚执行顺序导致的性能问题!
- JOIN的七种武器
记住这个口诀:“内连找交集,左连保左全,右连护右全,全连手拉手”。但实际开发中:
- 左连接使用率高达80%(特别是报表场景)
- 交叉连接要慎用!(曾经有个同事误操作导致百万级笛卡尔积…)
二、事务与锁机制(面试重灾区)
- ACID不是白开水!
用生活案例解释更生动:
- 原子性(Atomicity):转账要么全成功,要么全失败(就像网购付款)
- 隔离性(Isolation):朋友圈点赞不会影响其他用户的浏览(但实际数据库隔离级别有门道!)
- 隔离级别四重奏
一定!一定!要背下这个对照表(面试官最爱):
级别 | 脏读 | 不可重复读 | 幻读 | 使用场景 |
---|---|---|---|---|
读未提交 | ✔️ | ✔️ | ✔️ | 几乎不用 |
读已提交 | ✖️ | ✔️ | ✔️ | Oracle默认 |
可重复读 | ✖️ | ✖️ | ✔️ | MySQL默认 |
串行化 | ✖️ | ✖️ | ✖️ | 金融交易 |
- 死锁逃生指南
遇到死锁别慌!记住三板斧: SHOW ENGINE INNODB STATUS
查看死锁日志- 设置合理的锁等待超时时间(
innodb_lock_wait_timeout
) - 事务尽量短小精悍(我习惯用秒表计时,超过3秒的事务必须优化)
三、索引优化篇(性能关键)
- B+树索引的隐藏技能
很多新手不知道:
- 联合索引的最左前缀原则(就像手机号码前三位决定运营商)
- 覆盖索引能直接拿数据不用回表(相当于快递直接放门口)
- 索引下推(ICP)是MySQL5.6的神优化!(查询效率提升50%不是梦)
- EXPLAIN执行计划解读(送命题)
重点看这几个列:
- type:至少要达到range级别(all全表扫描等着被diss吧)
- key_len:计算索引使用长度(varchar需要+2,utf8字符+3)
- Extra:出现
Using filesort
赶紧跑路优化!
四、开发实战陷阱
- 分页查询的坑你踩过吗?
LIMIT 100000,10
为什么会慢?因为要遍历前10万条!优化方案:
-- 普通分页(小数据量)
SELECT * FROM table LIMIT 10 OFFSET 20;
-- 大数据量分页(记住这个模板!)
SELECT * FROM table WHERE id > 100000 ORDER BY id LIMIT 10;
- COUNT(*)的惊天秘密
别再纠结COUNT(*)和COUNT(1)的性能了!官方文档早就说明:
- MyISAM引擎直接返回元数据(秒出结果)
- InnoDB要实时计算(百万级数据可能卡死)
- 终极方案:用Redis维护计数(但要注意双写一致性)
五、高频灵魂拷问
-
为什么用自增主键?
这题答好了直接加分!要分三个层面: -
存储层面:顺序写入减少页分裂
-
查询层面:B+树范围查询效率高
-
业务层面:无意义ID更安全(防止被猜出业务量)
-
三大日志:binlog/redolog/undolog
用快递物流做类比:
- binlog是发货单(主从同步用)
- redolog是快递员的背包(崩溃恢复用)
- undolog是退货登记表(事务回滚用)
六、避坑指南(血泪经验)
- 永远不要相信用户输入(SQL注入是入门级错误)
- 字段定义NOT NULL(NULL值会让索引失效!)
- **禁用SELECT *** (特别是大表查询,曾经因此背过事故)
- 定期执行
ANALYZE TABLE
(优化器统计信息要及时更新)
最后的小技巧
面试遇到不会的问题时,可以这么说:“这个问题我之前主要关注在应用层面,能否请您提示下考察方向?”(亲测有效,能避免冷场!)
建议把这些知识点做成思维导图(我习惯用XMind),每天通勤时看一遍。记住,MySQL学得好,Offer拿到老!(实战中遇到有趣案例欢迎评论区交流~)