fix: add missing blank lines before lists in 01_mysql_redis.md

Author: ZeroJustMe

cpp_interview_notes/04_database_cache/01_mysql_redis.md

@@ -33,14 +33,17 @@ MySQL 和 Redis 放在一起问，核心不是让你背两个产品的特性，
 
 ### 更深入的理解
 索引的本质不是"让查询 magically 变快"，而是：
+
 - 提前按某种规则组织数据访问路径
 - 让查询少扫很多不必要的数据页
 
 如果没有索引，很多查询只能：
+
 - 从头到尾一行一行看
 - 或扫描大量无关页
 
 而有索引后，数据库可以：
+
 - 快速定位起点
 - 顺着有序结构继续扫范围
 - 减少磁盘 / buffer pool 的无效访问
@@ -59,6 +62,7 @@ B+ 树适合磁盘/页式存储，层高低、磁盘 IO 次数少，叶子节点
 ### 为什么不是红黑树？
 
 红黑树是二叉结构，树高通常更高。对于数据库这种页式存储来说：
+
 - 层高更高 → 访问路径更长
 - 磁盘/页 IO 次数更不友好
 
@@ -67,21 +71,25 @@ B+ 树适合磁盘/页式存储，层高低、磁盘 IO 次数少，叶子节点
 ### 为什么不是哈希？
 
 哈希适合：
+
 - 等值查询
 
 但它不擅长：
+
 - 范围查询
 - 排序
 - 最左匹配后的连续扫描
 
 而数据库索引特别常见的需求恰恰是：
+
 - `>`、`<`、`between`
 - `order by`
 - 范围过滤
 
 ### 为什么是 B+ 树，不是 B 树？
 
 B+ 树通常：
+
 - 非叶子节点只存键，不存整行数据
 - 单页能容纳更多索引项
 - 树更矮
@@ -98,12 +106,14 @@ B+ 树通常：
 ### 标准回答
 
 在 InnoDB 中：
+
 - **聚簇索引**叶子节点直接存整行数据
 - **二级索引**叶子节点存主键值，需要再根据主键去聚簇索引拿整行
 
 ### 更深入地理解
 
 这意味着：
+
 - 表数据本身就是按主键组织的
 - 主键访问通常路径最短
 - 二级索引查全字段时，可能需要两跳
@@ -136,6 +146,7 @@ B+ 树通常：
 ### 什么时候容易被追问？
 
 当面试官问：
+
 - 为什么某 SQL 走了索引还是慢？
 - explain 看起来用了 key，怎么性能还差？
 
@@ -154,6 +165,7 @@ B+ 树通常：
 因为它减少了一次访问主表/聚簇索引的过程。
 
 特别是在：
+
 - 命中行较多
 - 查询非常频繁
 - 热路径 SQL
@@ -163,6 +175,7 @@ B+ 树通常：
 ### 但不要走极端
 
 不是所有查询都应该为了覆盖索引去疯狂加字段，否则会带来：
+
 - 索引膨胀
 - 写入放大
 - 维护成本上升
@@ -226,11 +239,13 @@ B+ 树通常：
 ### 不要机械背表格
 
 更关键的是理解隔离级别是在权衡：
+
 - 并发性能
 - 锁冲突
 - 一致性强度
 
 隔离越强，通常：
+
 - 并发越受限
 - 实现成本越高
 - 吞吐可能越低
@@ -250,15 +265,18 @@ B+ 树通常：
 ### 为什么叫"幻"读？
 
 因为不是原有某一行变了，而是：
+
 - 范围里突然"冒出"了新的记录
 
 这和不可重复读的区别在于：
+
 - 不可重复读更像"同一行值变了"
 - 幻读更像"结果集成员变了"
 
 ### InnoDB 常见回答
 
 InnoDB 在可重复读级别下会结合：
+
 - MVCC
 - Next-Key Lock
 
@@ -275,10 +293,12 @@ MVCC（多版本并发控制）通过保存数据多个版本，使读操作无
 ### 它解决了什么问题？
 
 如果所有读都和写互相强阻塞：
+
 - 并发会很差
 - 热点表会很卡
 
 MVCC 的核心思想是：
+
 - 读不一定非要读"当前最新版"
 - 可以读一个对当前事务可见的历史版本
 
@@ -302,6 +322,7 @@ MVCC 的核心思想是：
 ### 更完整的理解
 
 Redis 快不只是"因为在内存里"，还因为它在工程上刻意追求：
+
 - 数据路径短
 - 命令模型简单
 - 单线程避免复杂锁竞争
@@ -310,6 +331,7 @@ Redis 快不只是"因为在内存里"，还因为它在工程上刻意追求：
 ### 但也别神化
 
 Redis 快并不意味着：
+
 - 所有命令都永远快
 - 大 key / 大范围操作没问题
 - 单线程就没有阻塞风险
@@ -327,17 +349,20 @@ Redis 快并不意味着：
 ### 更深入一点
 
 Redis 选择单线程核心执行模型，本质是在做一个工程取舍：
+
 - 放弃复杂共享内存并发
 - 换取实现简单、延迟稳定、锁开销低
 
 ### 这不代表 Redis "只有一个线程"
 
 实际系统中还可能有：
+
 - IO 线程
 - 后台持久化线程
 - 异步释放资源线程
 
 但命令执行核心路径长期以来强调的是：
+
 - 尽量串行
 - 尽量减少锁竞争
 
@@ -361,6 +386,7 @@ Redis 选择单线程核心执行模型，本质是在做一个工程取舍：
 ### 面试不要只背名字
 
 更重要的是知道它们分别适合：
+
 - String：缓存对象、计数器、分布式锁基础
 - Hash：对象字段聚合存储
 - Set：去重、共同好友、标签集合
@@ -500,6 +526,7 @@ Redis 选择单线程核心执行模型，本质是在做一个工程取舍：
 ## 进阶建议
 
 如果你想把这一章练到不怕追问，至少做到：
+
 - 能说清 B+ 树为什么适合数据库
 - 能解释回表和覆盖索引的性能意义
 - 能讲清事务隔离级别的权衡