MySQL
最主流的开源关系型数据库，业务数据的账本
MySQL 是绝大多数业务系统的“最终真相”：订单、用户、账务最后都落在它这里。它的核心就三件事——索引让查询变快，事务让并发写入不乱，主从复制让数据不丢、读请求能分摊。面试和工作里的问题，八成也集中在这三件事上。
它解决什么问题
业务数据必须准确、不能丢、不能出现“钱扣了订单没生成”。同时还要支撑高并发读写，单机迟早扛不住。
真实场景：典型场景：订单表按用户 ID 建索引，查询走 B+ 树三层的 IO；下单用事务包住扣库存和写订单；主库写、从库读，主库挂了切从库。
核心概念
每个概念一句话 + 一个类比。点击卡片看更详细的解释。
索引（B+ 树）
把数据按顺序组织成 B+ 树，用少量 IO 定位到行
类比：字典的拼音目录，不用一页页翻
看概念详情事务 ACID
一组操作要么全成功要么全失败，且互不干扰
类比：转账，扣钱和加钱必须同时生效
看概念详情隔离级别
读未提交/读已提交/可重复读/串行化，越往后越安全越慢
类比：会议室的玻璃，从透明到磨砂到独立隔间
看概念详情MVCC
靠 undo log 版本链 + ReadView 实现“读不加锁”
类比：文档的历史版本，你读你打开时的那一版
看概念详情主从复制
主库写 binlog，从库重放，实现备份和读写分离
类比：账本誊抄，正本写完抄一份副本
看概念详情数据流转动画
跟着步骤看一条数据从进入系统到被处理完的完整路径，可以暂停、重播和调速。
一条 SQL 从连接到落盘
← 左右滑动查看完整流程图 →
应用从连接池取一条连接，认证后开始执行 SQL。
提示：重点看两层：Server 层负责“怎么查”，InnoDB 层负责“怎么存”。 悬停图中的节点可以看概念解释。
优劣势
短句说清适合什么、不适合什么，选型时先看这一栏。
- 事务和强一致，账务类场景的默认选择
- 索引优化成熟，SQL 生态和工具链最全
- 主从 + MHA/Orchestrator 高可用方案成熟
- 人才储备多，出问题容易找到答案
- 水平扩展难，分库分表要自己扛
- 单表数据量大后 DDL 和查询都会变慢
- 复杂 JSON、嵌套结构表达不自然
- 高并发写入受单机上限约束
常见使用场景
每个场景都配一句「为什么用它」。
交易与订单系统
订单、支付流水、库存扣减，全部放在事务里。
为什么用它：ACID 保证钱和单据不会对不上。
用户与权限数据
用户表、角色表、权限关联表，强关系查询。
为什么用它：多表 JOIN 和唯一约束是关系库的强项。
报表与统计查询
按时间、维度做聚合统计。
为什么用它：SQL 表达力强，配合索引和物化表够用。
同类对比
和同赛道的组件并排看，差异一目了然。
多数公司是混用：交易数据在 MySQL，商品详情和日志在 MongoDB。别为了「不用改表」把账务数据放进文档库。
常见问题
上手第一个月最容易卡住的地方。
Q1索引失效的常见场景？
对索引列做函数或运算、隐式类型转换（字符串列传数字）、前导模糊 LIKE '%x'、OR 连接的列没都建索引、联合索引不满足最左前缀、优化器判断全表更快。
Q2事务隔离级别有什么区别？
读未提交会脏读；读已提交解决脏读但有不可重复读；可重复读（MySQL 默认）解决不可重复读，靠 MVCC 大部分场景避免幻读；串行化全加锁，性能最差。
Q3为什么 MySQL 用 B+ 树不用 B 树或红黑树？
B+ 树非叶子节点只存键，一页能放更多索引项，树更矮（三层可存两千万行）；叶子节点用链表相连，范围查询顺序扫描很快。红黑树高度太高，磁盘 IO 次数多。
Q4深分页 limit 1000000,10 为什么慢？
要扫描并丢弃前一百万行。优化方式：用上次的最大 id 做游标（where id > lastId limit 10），或先查主键再回表。
Q5主从延迟怎么处理？
写后立即读的场景强制走主库；用半同步复制减少延迟；从库并行重放（MTS）；业务上做补偿查询。延迟大到无法接受时，考虑分片或换存储。