没有索引时会发生什么#

假设 orders 有 1000 万行，查询：

SELECT *
FROM orders
WHERE user_id = 2001;

如果 user_id 没有索引，数据库无法直接定位匹配行，只能执行全表扫描（Full Table Scan），逐页检查大量甚至全部记录。数据量越大，查询成本和 Buffer Pool 压力越高。

为 user_id 建立索引后，数据库可以先在索引中定位少量候选记录，再回表读取 完整行。索引的核心作用就是缩小需要扫描的范围，而不是“加速”这个动作本身。

B+ Tree 与 Page#

索引的目标是减少需要访问的数据量。InnoDB 最常用的索引结构是 B+ Tree，一种 多叉平衡搜索树：

            [20 | 40]
          /     |     \
     [1..19] [20..39] [40..]

非叶子节点保存键和子节点指针，数据主要位于叶子节点，叶子之间通常还有链表 连接，便于范围扫描。

数据库不以“一条记录一次磁盘读取”为单位，而以 Page 为基本 I/O 单位。InnoDB 默认页大小是 16 KB，可以通过 innodb_page_size 调整。一个页能容纳大量键值， 使 B+ Tree 的扇出（fan-out）很大。即使表有数百万行，树高通常仍只有几层， 查询需要的页访问次数远少于普通二叉树。

这也解释了数据库为什么不用二叉搜索树：真正的成本通常不是 CPU 比较，而是 Page I/O。索引设计本质上是在减少需要读取的页数。

聚簇索引、二级索引与回表#

InnoDB 的主键索引是聚簇索引，叶子节点直接保存整行：

Primary Key -> B+ Tree -> Row

其他索引是二级索引（Secondary Index）。例如：

CREATE INDEX idx_user_id ON orders(user_id);

idx_user_id 的叶子节点通常保存 user_id 和主键 id，而不是完整行。通过 二级索引找到主键后，还需要回到聚簇索引取整行，这个过程称为回表：

如果查询需要的列都已经在索引中，就不必回表。例如：

SELECT user_id, id
FROM orders
WHERE user_id = 2001;

这时 idx_user_id 同时提供了过滤条件和返回列，属于覆盖索引（Covering Index）。执行计划中的 Extra 出现 Using index，通常表示使用了覆盖索引； Using index condition 表示索引条件下推，并不等于覆盖索引。

覆盖索引能减少随机 I/O，但会让索引变宽。是否需要为某个查询专门扩展索引， 仍要结合读写比例判断。

联合索引与最左前缀#

联合索引由多个列组成，列顺序决定它能服务哪些查询：

CREATE INDEX idx_user_status_time
ON orders(user_id, status, created_at);

它按 user_id、status、created_at 依次排序，因此通常可以支持：

(user_id)
(user_id, status)
(user_id, status, created_at)

只按 status 查询通常无法有效利用这棵索引，因为同一 status 的记录散落在 不同 user_id 的分支中。这就是最左前缀原则。

范围条件会截断后续列的定位能力。例如：

SELECT *
FROM orders
WHERE user_id = 2001
  AND status > 'A'
  AND created_at = '2026-11-01';

user_id 可以用于定位，status 可以做范围扫描，但 created_at 通常无法 继续用于精确查找，只能在该范围内过滤。联合索引的列顺序要围绕真实查询模式 设计，而不是把所有字段随意堆在一起。

索引不是越多越好#

每增加一个索引，查询可能更快，但 INSERT、UPDATE、DELETE 都要维护更多 索引结构，带来额外的存储、写放大和 Buffer Pool 压力。低选择性的索引还可能 被优化器放弃。

索引是读性能与写成本之间的权衡。一个表有十几个“可能有用”的索引，往往说明 查询模式没有被认真收敛。

优化器与 EXPLAIN#

SQL 执行前会经过查询优化，数据库需要决定使用哪个索引、连接顺序、扫描方式和 执行计划。因此“建了索引”不等于“查询一定用索引”。

EXPLAIN 用于查看执行计划：

EXPLAIN
SELECT id, status
FROM orders
WHERE user_id = 2001;

重点观察：

rows 是优化器基于统计信息的估算，可能因数据分布、统计信息过期或索引选择 而偏差很大。分析慢查询时，应结合真实执行时间、扫描行数和 EXPLAIN ANALYZE 等工具，而不是只看 key 是否有值。

四种隔离级别#

SQL 标准定义了四种常见隔离级别：

Read Uncommitted 允许读取另一个事务尚未提交的修改。如果对方随后回滚，读到 的值可能从未真正存在过，这就是脏读。

Read Committed 只允许读取已提交数据，避免脏读，但同一事务内两次查询可能 看到不同结果。例如第一次读到 status=CREATED，另一个事务提交了 status=PAID，第二次就读到新值，称为不可重复读。

Repeatable Read 希望同一事务中的一致性读取看到稳定快照。MySQL InnoDB 默认 使用 Repeatable Read，并通过 MVCC 提供一致性读。Serializable 提供更强隔离， 效果接近串行执行，但并发能力通常下降，不是所有系统都适合最高级别。

需要区分“标准定义”和“具体实现”。InnoDB 在 Repeatable Read 下，普通一致性 读依靠 Read View 避免幻读，当前读则依靠 next-key lock 处理范围并发。是否 完全避免幻读，还取决于读类型、索引和访问路径，不能只凭隔离级别名称推断。

MVCC 让读写少互相阻塞#

MVCC（Multi-Version Concurrency Control，多版本并发控制）的核心思想是： 同一条记录可以存在多个逻辑版本，不同事务按自己的可见性规则读取合适版本。

如果每次读取都必须给行加排他锁，高并发下读写会严重互相阻塞。MVCC 允许大量 一致性读在不与普通写长期互斥的情况下完成。

普通 SELECT 在适当隔离级别下通常是快照读（Snapshot Read），根据事务的 可见性读取某个历史版本。SELECT ... FOR UPDATE 或 FOR SHARE 则是当前读 （Current Read），需要读取最新版本并加锁。

历史版本来自 Undo Log。Undo Log 除了支持回滚，还能帮助构造旧版本。Read View 则是一组可见性规则，用来判断某个版本对当前事务是否可见。因此 MVCC 不是 把数据库完整复制多份，而是通过事务 ID、Undo 版本和可见性判断实现逻辑多版本。

在 Repeatable Read 下，Read View 通常在事务第一次一致性读时建立；在 Read Committed 下，每条语句可能建立新的 Read View。这解释了两者在“同一事务内 是否看到新提交数据”上的差异。

死锁与重试#

死锁发生在多个事务互相等待对方持有的资源：

Transaction A: 锁 Row 1，等待 Row 2
Transaction B: 锁 Row 2，等待 Row 1

形成循环等待后，InnoDB 会检测并回滚其中一个事务，应用通常收到死锁错误。 应用层需要有限次重试，并配合退避和幂等，不能无限重试。

降低死锁的常见方法：

• 保持事务短小；
• 固定资源的加锁顺序；
• 使用合适索引，减少扫描和锁定范围；
• 避免在事务中执行长时间外部调用；
• 减少大范围更新和批量操作。

长事务的代价#

长事务会带来一系列连锁影响：

• 锁持有时间长，阻塞其他事务；
• Undo 堆积，历史版本无法及时清理；
• Purge 延迟，Undo 表空间膨胀；
• 主从复制延迟；
• 连接池资源被长期占用；
• 并发能力下降。

因此事务不应该无意义地覆盖整个业务流程。尤其要避免下面这种结构：

Begin Transaction
Update DB
Call Remote API（等待 10 秒）
Commit

远程调用期间，数据库事务一直没有结束。更合理的分布式一致性模式包括 Outbox、 消息、Saga 和补偿，把“本地事务”和“跨服务协作”分开处理，避免把外部系统的 等待时间塞进数据库事务。

连接耗尽与连接泄漏#

如果应用获取连接后没有正确归还，就会出现连接泄漏。连接池逐渐耗尽，所有请求 都在等待连接。表现可能像“数据库很慢”，实际却是应用没有关闭资源。

使用 try-with-resources 或框架管理连接，并配置泄漏检测阈值，可以在开发阶段 更早发现问题。

如果数据库连接被占满，新的连接请求可能收到 Too many connections。此时应用 看到的不是某条 SQL 变慢，而是整个连接池无法获取连接。排查时要同时看数据库 端的连接来源、应用实例数和池配置。

连接池和数据库访问还需要几类超时：

如果获取连接要等 3 秒，就应该快速失败，而不是让请求无限堆积。SQL 本身也需要 超时：一条执行两分钟的查询会长期占用连接、线程和数据库资源，并可能在应用 已经超时后继续运行。

连接池解决的是连接复用，不解决慢查询、锁等待或事务过长。数据库访问性能要 同时看 SQL 成本、网络往返、连接获取、锁等待和排队时间。

只读副本与复制延迟#

Read Replica（只读副本）承担读流量，把写留在 Primary：

读写分离可以扩展读能力，但副本通常不是完全实时同步，可能存在 Replication Lag。Primary 刚写入 status=PAID，立刻读副本可能仍看到 CREATED。

这涉及 Read-after-Write Consistency（写后读一致性）。支付后立即确认状态、 下单后立即查询订单等场景，通常应走 Primary 或采用会话粘滞、版本校验等策略。 报表、分析和非强实时查询更适合副本。

选择读副本的依据是业务能容忍多旧的数据，而不是“读请求都应该分散”。

备份解决的是另一类问题#

高可用和备份不是同一件事。如果用户误执行：

DROP TABLE orders;

Primary 会执行，复制也可能把删除同步到 Standby。主备切换无法恢复被逻辑删除 的数据，只有备份和时间点恢复（Point-in-Time Recovery）才能回到过去某个时刻。

备份通常包括全量备份、增量备份和 Binlog 等连续日志。恢复目标用两个指标描述：

• RPO（Recovery Point Objective）：最多允许丢失多少数据，例如 5 分钟；
• RTO（Recovery Time Objective）：系统需要多快恢复，例如 30 分钟。

RPO 关注“能丢多少”，RTO 关注“能停多久”。两者需要同时设计，不能只用“有备份” 作为答案。

Cache-Aside#

最常见的缓存模式是 Cache-Aside：应用先读缓存，未命中再读数据库，并把结果 写回缓存：

如果热点接口有 10000 QPS，其中 95% 命中 Redis，MySQL 只需要处理约 5% 的读 流量。这就是缓存层的主要价值。

但增加 Redis 不会自动让系统变快。Key 设计错误、命中率低、TTL 不合理或更新 策略错误，都会让缓存变成额外的复杂度和故障点。Cache Hit Rate（命中率）是 评估缓存效果的核心指标：

Hit Rate = Hit / (Hit + Miss)

缓存一致性#

缓存最大的问题是 MySQL 和 Redis 可能出现两个版本的数据。常见更新方式有两种：

先更新数据库，再更新缓存
先更新数据库，再删除缓存

更常见的是第二种：更新数据库后删除缓存，让下一次读取重新加载。原因在于缓存 里的值可能不是一行记录的简单复制，而可能是聚合结果、DTO 或多表计算结果。 直接更新缓存容易遗漏逻辑，删除则把重建责任交给读路径。

也不推荐先更新缓存再更新数据库：如果缓存更新成功而数据库失败，缓存就成了 与权威数据源不一致的“新数据”。

sequenceDiagram
    participant App
    participant DB as MySQL
    participant Redis

    App->>DB: UPDATE ...; COMMIT
    DB-->>App: OK
    App->>Redis: DEL user:1001

即使采用“更新数据库后删除缓存”，仍然存在并发窗口。例如读请求在数据库更新 前读到旧值，更新完成后删除缓存，读请求随后把旧值写回缓存。这类问题很难靠 单条命令彻底消除。

因此缓存架构通常追求最终一致性，而不是强事务一致性。对于账户余额、支付状态、 库存最终决策等强一致要求的数据，核心判断仍应依赖数据库事务，不能把 Redis 缓存当成权威数据源。

缓存穿透#

缓存穿透（Cache Penetration）是查询数据库中本来就不存在的数据。攻击者不断 访问 userId=-1、userId=-2，Redis 永远未命中，MySQL 每次都收到查询，缓存 层完全失去作用。

常见应对：

• 缓存空值：数据库返回 Not Found 时，短时间缓存 NULL，例如 TTL 60 秒；
• 布隆过滤器：快速判断元素是否可能存在，判断“不存在”时一定不存在，判断 “存在”时可能有假阳性；
• 参数校验与限流：在入口拒绝明显非法的 ID 和异常高频请求。

空值缓存要设置较短 TTL，避免大量无效 Key 占用内存。布隆过滤器需要维护位图 和误判率，删除元素也比较困难，适合“只增不删”的 ID 集合。

缓存击穿#

缓存击穿（Cache Breakdown）通常发生在一个极热点 Key 突然失效时。例如 hot-product 的 TTL 到期，同时有 10000 个请求到达，全部未命中并同时访问 MySQL。

常见应对：

• Mutex：第一个请求获得锁，负责查询数据库和重建缓存，其他请求等待或降级；
• Single Flight：同一进程内合并相同 Key 的并发加载；
• 逻辑过期：Value 中保存过期时间，物理上不设 TTL，由异步任务刷新；
• 热点 Key 永不过期，配合后台异步更新。

互斥锁能保护数据库，但锁本身也可能成为瓶颈。Single Flight 只在单个 Pod 内 有效，多 Pod 同时未命中时仍需要分布式协调或接受多次查询。

缓存雪崩#

缓存雪崩（Cache Avalanche）是大量 Key 在短时间内集中失效。比如 100 万个 Key 的 TTL 都是 3600 秒，并且同一时间写入，一小时后会同时过期，数据库流量突然 暴涨。

常见应对：

• TTL Jitter：在基础 TTL 上增加随机偏移，例如 3600 秒加 0 到 600 秒；
• 多级缓存：本地缓存加 Redis，减少对单一层的依赖；
• 限流与熔断：保护数据库不被瞬时流量打垮；
• 容量保护：为缓存和数据库预留突发余量；
• 缓存预热：系统启动或缓存恢复后主动加载热点数据。

TTL Jitter 的实现很简单：

expire = 3600 + random(0, 600)

它不能消除雪崩，但能把集中失效打散到一段时间内。

穿透、击穿、雪崩的共同点是“请求绕过缓存打到数据库”。因此防护要分层：入口 限流、缓存层保护、数据库容量和降级策略都不能缺。

Sentinel 与 Cluster#

Redis 可以建立 Primary / Replica 复制，用于高可用和读扩展。Sentinel（哨兵）监控 主从节点并在故障时执行切换：

Primary Failure -> Detect -> Promote Replica

Sentinel 解决的是同一份逻辑数据集的高可用，不做数据分片。Redis Cluster 则 把数据分散到多个节点，通过 16384 个 Hash Slot 映射 Key：

Key -> CRC16 -> Slot -> Node

多 Key 操作通常要求落在同一个 Slot，可以使用 Hash Tag 把相关 Key 放到一起。 Cluster 同时提供分片和一定的高可用能力，但运维复杂度和客户端要求更高。

热 Key 与大 Key#

热 Key 是单个 Key 承受极高访问量。例如首页热榜占据 40% 的 Redis 请求，即使 集群总容量足够，承载该 Key 的单个节点仍可能成为瓶颈。应对方式包括本地缓存、 Key 拆分、读写分离和请求合并。

大 Key 是单个 Key 的数据体积过大，例如一个 Hash 有 100 万个 Field。问题包括 网络传输慢、删除耗时、阻塞 Redis 主线程和复制压力。可以用 UNLINK 异步删除， 但更根本的做法是拆分 Key、压缩数据，避免把大对象塞进 Redis。

Redis 适合高频、低延迟、小对象访问。大型文件应该放 OBS，复杂关系数据应该 放 MySQL。它不是“什么数据都可以扔进去”的万能存储。

N+1 查询#

ORM 使用中常见 N+1 Query Problem。查询 100 个订单时，先执行一次订单查询， 再为每个订单查询一次用户，最终产生 101 条 SQL：

1 次 Order Query
+ 100 次 User Query
= 101 次数据库往返

开发环境只有 10 条数据时问题不明显，生产环境有 10000 条时就会产生大量 SQL 和网络往返。优化时不能只看单条 SQL 的成本，还要看一次请求的总查询次数。

更合理的方式是批量查询：

SELECT *
FROM users
WHERE id IN (...);

或者使用 Join、批量加载。数据库往返次数本身就是性能成本的一部分。

Schema 迁移与 Expand and Contract#

应用发布不只是新镜像，还可能包含数据库 Schema 变化：

ALTER TABLE orders
ADD COLUMN channel VARCHAR(32);

Rolling Update 期间，v1 和 v2 Pod 可能同时存在。如果直接删除旧字段，v1 可能 立刻访问失败。数据库迁移必须考虑版本兼容：

Expand：先增加新结构，保持旧结构可用
Migrate：新旧版本同时兼容，逐步迁移数据
Contract：确认旧版本完全消失后，再删除旧结构

这称为 Expand and Contract。它把一次破坏性变更拆成多个可回滚的步骤。

数据库发布比 Pod 回滚更复杂。Pod 可以从 v2 快速回滚到 v1，但 DROP COLUMN 无法通过 Kubernetes Rollback 恢复。Schema 变更必须单独设计回滚路径、备份和 兼容窗口。

RDS 和 Kubernetes 的生命周期也不同。Pod 是临时的，可以删除重建；数据库是 长期保存状态的基础设施，删除后重建为空实例意味着数据丢失。不能把数据库 当成普通 Deployment 管理。

主要监控指标#

Redis 内存达到上限时，会根据 maxmemory-policy 驱逐 Key。默认的 noeviction 会拒绝写入，allkeys-lru、volatile-lru 等策略则会删除部分 Key。大量热 Key 被驱逐会降低命中率，随后 MySQL QPS 上升。于是：

Redis Memory Pressure
-> Cache Eviction
-> Hit Rate Drop
-> MySQL Overload

这条因果链说明，缓存指标和数据库指标必须一起看。单独看 Redis 内存或单独看 MySQL QPS，都可能错过真正的原因。

缓存预热与降级#

如果缓存被整体清空，100 个 Pod 同时收到请求，全部会 Cache Miss，数据库瞬间 承受全量流量。这称为缓存冷启动压力。对首页商品、全局配置、热榜等极热点数据， 可以在启动或缓存恢复后主动预热。

Redis 故障时，也不是所有请求都必须访问 MySQL。非关键接口可以返回旧数据、 默认值或临时关闭功能，这属于优雅降级（Graceful Degradation）。缓存中已有的 数据也能在数据库短时故障时继续服务部分读请求，但缓存不完整、TTL 会到期， 不能把 Redis 当成数据库容灾方案。