全书目录

第十八篇：MySQL 完全指南 —— 城市户籍总账宇宙

第十五章：什么时候适合用 MySQL，什么时候不适合硬上

4 分钟 1,561 字 第 350 / 962 个阅读单元

适合 MySQL 的场景

  • 业务数据结构相对清晰，实体关系稳定
  • 强依赖事务一致性，比如订单、账户、审批、户籍、库存
  • 经常需要多表关联查询
  • 读写并发都比较高，但仍然以 OLTP 业务为主
  • 需要成熟、稳定、可运维的关系型数据库底座

不太适合单靠 MySQL 的场景

  • 结构变化极其频繁、文档形态高度自由的数据
  • 超大规模全文搜索为核心的检索系统
  • 主要工作负载是超重型分析型查询、海量历史聚合
  • 图关系遍历特别复杂的场景
  • 超高吞吐的纯日志/时序写入，且主要诉求不是关系查询

这不代表 MySQL 不能碰这些活，而是：

它未必是这类问题的最优主角。

最后把整个“城市户籍总账宇宙”串成一张概念图：

text
应用请求
  │
  ▼
SQL 语句
  │
  ▼
MySQL 户籍总账楼
  │
  ├── database（一本业务总账）
  │   ├── table（分账册）
  │   │   ├── row（一条户籍登记）
  │   │   ├── column（登记栏目）
  │   │   ├── primary key（总编号）
  │   │   ├── constraints（规章）
  │   │   └── index（目录卡）
  │   └── relation（账册之间的挂接关系）
  │
  └── InnoDB 办理系统
      ├── transaction（一次完整办理）
      ├── isolation level（并发窗口规则）
      ├── consistent read（快照翻账）
      └── lock（柜台占用控制）

如果只记一条主线，请记这句：

MySQL 不是“会写几句 SQL”就算会了。
真正入门，是把它看成一座有账册结构、目录系统、办理规章和并发秩序的城市户籍总账楼。

#官方来源链接清单