09 - 总结：数据库优化决策树

走到最后一章。整个系列的核心不是某个具体技术，而是一条有优先级的优化路径。这一章把它汇成一张决策树和速查表。

一句话总结全系列：数据库优化是有顺序的——从最便宜的索引，到 SQL、缓存、读写分离、分区表，最后才是分库分表这个重武器。永远从性价比最高的开始。

9.1 数据库优化决策树（核心）

数据库慢 / 扛不住？
      │
      ▼
① 先用 EXPLAIN 定位：慢在哪条 SQL？走没走索引？
      │
      ├─ 全表扫描 / 缺索引？
      │     → 【索引优化】建索引、联合索引、覆盖索引（01-03章）★最先做
      │
      ├─ 索引也有了，SQL 还是烂？
      │     → 【SQL/表结构优化】改写 SQL、避免深分页、优化字段类型（04章）
      │
      ├─ 读请求太多，重复查同样数据？
      │     → 【缓存】Redis 挡在数据库前（05章）
      │
      ├─ 读远多于写，缓存也扛不住？
      │     → 【读写分离】写主库、读从库（05章）
      │
      ├─ 单表行数太大，但单机还够用？
      │     → 【分区表】PostgreSQL 原生分区，对应用透明（05章）
      │
      └─ 单机物理到顶了（磁盘/写QPS/连接数）？
            → 【分库分表】最后的重武器，慎用（06-08章）
      │
      ▼
② 每一步之后都用 EXPLAIN / 压测验证效果

9.2 优化手段速查表

表格从上到下：性价比递减、复杂度递增。请从上往下依次考虑，能在上面解决就别往下走。

9.3 索引知识速查

【怎么建】
  · 高频查询、高区分度的列
  · 联合索引遵守「最左前缀」，高频列放左边
  · 需要的字段都进索引 → 覆盖索引，免回表

【为什么没走索引（索引失效）】
  · 列上做运算/用函数
  · LIKE '%x' 以通配符开头
  · 隐式类型转换
  · 违反最左前缀
  · 优化器觉得全表扫描更快（表太小/区分度太低）

【怎么验证】
  · EXPLAIN ANALYZE：看是 Seq Scan 还是 Index Scan，看实际耗时

9.4 分库分表知识速查

【什么时候才分】
  前面所有招用尽 + 瓶颈是单机物理极限 + 数据持续高速增长

【怎么拆】
  · 垂直拆：按业务/字段（解决耦合、宽表）
  · 水平拆：按行（解决行数太多）——范围/哈希/时间
  · 分片键：贴最高频查询维度、分布均匀、几乎不变（最关键）

【会带来什么新问题】
  · 主键冲突   → 分布式 ID（雪花算法）
  · 跨库查询   → 冗余/ES/尽量带分片键
  · 分布式事务 → 尽量同片内、最终一致
  · 扩容迁移   → 预分片/一致性哈希

9.5 五条核心心法

1. 先测量，用 EXPLAIN 说话 —— 别凭感觉优化
2. 从便宜到昂贵 —— 索引 → SQL → 缓存 → 读写分离 → 分区 → 分库分表
3. 80% 的问题，索引和 SQL 就能解决 —— 别动不动想分库分表
4. 分库分表是重武器 —— 用巨大复杂度换单机上限，慎之又慎
5. 分片键定生死 —— 一旦选错，改起来要人命，一开始就想清楚

9.6 和其他系列的联系

这个系列是「数据库层」的优化，它和你学过的其他内容连成一张网：

• 《服务端高并发优化》 → 本系列是它「数据库层」那一环的深入展开
• 《数据库锁详解》 → 优化时绕不开锁和并发（长事务、行锁、MVCC）
• 《Redis 入门》 → 缓存这一招的具体实现
• 《消息队列入门》 → 分布式事务「最终一致」方案的基础设施

结语

数据库优化没有魔法，只有顺序和权衡。记住那句贯穿全系列的话：

从最便宜的索引开始，一步步往上加手段，把「分库分表」留到最后。80% 的性能问题，在前两步（索引 + SQL）就能解决。

遇到慢数据库时，别慌，也别急着上重武器——打开 EXPLAIN，从索引开始。

上一章 ← 08 - 分库分表带来的新问题 ｜ 回到 README