一、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拿到老！（实战中遇到有趣案例欢迎评论区交流~）
5036
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
