文章目录
一、高频问题轰炸(建议全文背诵版)
1. 索引连环问(必考!!!)
“为什么用B+树不用红黑树?”——这题简直是面试官的最爱!记住这三个致命点:
- 扇出率高:B+树一个节点能存几百个子节点(红黑树只有2个)
- 范围查询快:叶子节点形成链表,扫区间比红黑树快10倍不止
- 高度更低:千万级数据只要3层搞定(红黑树要20+层)
2. 事务四大特性(ACID)深度拆解
你以为背出原子性、一致性就完了?面试官要的是深入骨髓的理解:
- 原子性:UNDO日志实现(突然断电也不怕)
- 隔离性:MVCC+锁机制双保险(并发控制的灵魂!)
- 一致性:开发者最容易踩的坑(不是数据库自动保证的!)
- 持久性:REDO日志的骚操作(先写日志再写数据)
3. 锁机制生存指南
遇到"共享锁和排他锁区别"这种送分题时,一定要秀出进阶理解:
-- 行锁的经典场景
SELECT * FROM users WHERE id=1 FOR UPDATE; -- 排他锁锁定整行
(敲黑板)间隙锁才是大杀器!防止幻读就靠它,但也是死锁的罪魁祸首!
二、实战优化宝典(来自血泪教训)
1. EXPLAIN执行计划破译
看到Using filesort别慌!试试这两个急救方案:
- 建立复合索引(注意字段顺序!)
- 强制走索引:
FORCE INDEX(index_name)
2. 慢查询急救三板斧
上周刚救活一个10秒的查询,我的操作步骤:
- 打开慢查询日志(long_query_time=2秒)
- 用pt-query-digest分析(这工具真香!)
- 加索引+改写SQL(子查询改JOIN成功率80%)
3. 分页查询优化绝招
百万数据分页卡成狗?试试这个黑魔法:
-- 传统写法(性能杀手!)
SELECT * FROM table LIMIT 1000000,10;
-- 优化版(速度提升100倍!)
SELECT * FROM table WHERE id > 1000000 LIMIT 10;
三、灵魂拷问应对策略
1. “为什么主键推荐自增?”
这题暗藏三个杀机:
- 页分裂问题(随机主键导致性能下降50%)
- 写入性能(顺序写入比随机快3倍)
- 索引维护成本(B+树结构调整频率)
2. “MVCC实现原理”
别光说版本号!要画出undo日志链:
- 每个事务有唯一事务ID
- ReadView判断可见性
- 通过回滚指针追溯历史版本
3. “三大日志的相爱相杀”
REDO/UNDO/BINLOG三角关系图解:
- REDO:保证持久性(物理日志)
- UNDO:保证原子性(逻辑日志)
- BINLOG:主从复制核心(statement/row/mixed格式)
四、死亡陷阱题预警
1. COUNT(*) 的巨坑
面试官阴险三连问:
- COUNT(*)和COUNT(1)哪个快?
- COUNT(id)会走索引吗?
- 为什么MyISAM计数这么快?
正确答案:其实COUNT(*)经过优化器处理,和COUNT(1)没区别!MyISAM有元数据缓存所以快,但带WHERE条件就现原形!
2. JOIN原理大揭秘
当被问到"JOIN的执行过程",请祭出这个神图:
- 驱动表全表扫描(小表优先!)
- 被驱动表走索引查询
- 使用BNL算法(如果没索引)
3. 最左前缀原则的隐藏考点
你以为知道INDEX(a,b,c)能走a、ab、abc就完了?这些情况才是大坑:
- WHERE b=1 AND a=1 → 能用吗?(可以!优化器会调整顺序)
- WHERE a>1 AND b=1 → b条件还有用吗?(没用!范围查询截断)
五、压轴题:数据库设计核心理念
1. 范式与反范式的抉择
血泪教训:三范式不是银弹!电商系统的商品表就要适当反范式:
- 把销量、库存等高频字段冗余
- 用空间换时间(SSD这么便宜!)
- 但要注意数据一致性维护
2. 分库分表生死局
当面试官露出神秘微笑:“说说分库分表方案”,请按这个节奏输出:
- 垂直拆分优先(用户库、订单库分离)
- 水平拆分用一致性哈希(避免热点问题)
- 中间件选型(ShardingSphere还是MyCat?)
3. 终极灵魂拷问
“如果让你设计一个数据库,你会考虑哪些方面?”——死亡问题标准答案框架:
- 存储引擎架构(插件式设计)
- 事务实现方案(锁+MVCC)
- 日志系统设计(WAL原则)
- 内存管理策略(BufferPool机制)
(看完不点赞?信不信索引失效!)记住:面试不是背答案,而是展现解决问题的思维。把这些知识点内化成自己的理解,遇到变形题也能见招拆招。最后送大家一句话:索引建得好,下班回家早;事务用得溜,bug绕道走!

1259

被折叠的 条评论
为什么被折叠?



