MySQL
MySQL 是最常见的关系型数据库之一，常见于 Web 应用和通用 OLTP 场景，优势在于生态成熟、运维经验丰富与业务落地成本低。
#type / resource
#status / growing
#tech / dev / backend
#resource / mysql
[!info] related notes
MySQL
这是什么
MySQL 是一款面向通用业务系统的关系型数据库，最常见的默认存储引擎是 InnoDB。它在 Web 后端、业务系统和中小到中大型 OLTP 场景里非常常见。
如果只用一句更工程化的话描述它，可以理解成：
- 一款大量团队都能快速上手
- 大量框架、ORM、云服务和运维工具都优先适配
- 在“典型业务主库”这个位置上非常成熟的数据库
为什么它这么常见
MySQL 在工程实践里常见，不只是因为“历史悠久”，还因为它同时满足了很多团队的现实需求：
- 好找资料
- 好招人
- 好接各种后端框架和云服务
- 常见业务系统的性能与事务需求通常都能覆盖
所以它经常成为：
- 初学服务端数据库的第一站
- Web 业务系统的默认主库候选
- 很多公司历史系统和新系统都能接受的折中选择
适用平台 / 适用场景
- 中小型到中大型业务系统
- 常规 CRUD 为主的 Web 应用
- 订单、账号、内容管理、管理后台等 OLTP 场景
- 团队希望快速落地、资料丰富、工具生态成熟
核心特点 / 优势 / 局限
核心特点
- 典型部署方式是独立数据库服务
- 常见事务与并发能力主要围绕 InnoDB 展开
- 在业务开发语境里，经常和 ORM、迁移工具、主从复制、备份恢复一起出现
优势
- 生态成熟，教程、运维经验和排障案例多
- Web 应用和通用业务系统里极其常见
- InnoDB 提供事务、MVCC、日志恢复和较完整的并发控制能力
- 很多框架、云数据库产品和托管服务对 MySQL 兼容性优先级很高
局限
- 某些高级类型、约束表达力和扩展能力不如 PostgreSQL 灵活
- 当业务越来越依赖复杂查询、强约束、扩展索引或数据库内表达力时，团队可能更偏向 PostgreSQL
- 很多人因为 MySQL 常见而低估其事务、日志和并发细节，结果在边界场景里吃亏
从原理角度理解 MySQL，最该先抓住什么
1. 学 MySQL，不能只学 SQL 语法
真正决定业务行为的，往往是这些层：
如果只会写 SELECT、INSERT、UPDATE，但不理解这些机制，就很难解释：
- 为什么会锁等待
- 为什么会死锁
- 为什么提交成功后还能恢复
- 为什么默认行为和 PostgreSQL 不一样
2. MySQL 很强的地方是“工程默认值足够常用”
很多业务系统需要的不是极致理论优雅，而是：
- 成熟主库
- 成熟运维
- 成熟迁移方案
- 成熟生态
MySQL 的价值经常就体现在这里。
3. 但“常见”不等于“简单”
MySQL 常见，容易让人误以为它只是“更会跑 CRUD 的数据库”。其实只要深入事务、并发、日志和索引，它同样有很多需要系统理解的内部机制。
常见用途
- 业务主库
- 订单、账号、内容管理等 OLTP 场景
- 需要 ORM、迁移工具、管理工具快速配套的后端项目
- 大量历史系统和新业务都能接受的通用数据库基座
和 PostgreSQL 相比时最常见的认知差异
一个很常见的工程心智模型是：
- MySQL 更像“最常见的通用业务主库”
- PostgreSQL 更像“表达力更强、类型和扩展更丰富的通用主库”
这不是绝对划分，但对入门阶段很有帮助。
具体对照可继续看：