大多数团队并不是不懂 MySQL，而是从来没系统性地理解它——下面这些场景你一定不陌生。
页面打开要好几秒，明明数据量不大，问题却查不出来——问题往往出在没走索引的全表扫描上。
为了优化随手加索引，结果写入变慢、磁盘膨胀，索引建了一堆却没一个真正被用上。
误删一张表、硬盘故障、机房断电，等数据真的丢了才发现备份是摆设，恢复演练从来没做过。
把存储引擎、索引、事务、备份、高可用这五件事吃透，90% 的数据库问题都能在发生前被预防。
事务、行级锁、外键、崩溃恢复全部内置，为业务而生；只在极少数只读场景才考虑其他引擎。理解引擎差异，是从"会用"到"用对"的第一步。
B+Tree 主键索引、二级索引、联合索引、覆盖索引各有适用场景。学会看执行计划，就能判断一条 SQL 到底快在哪、慢在哪。
ACID 四个特性、MVCC 多版本控制、行锁与间隙锁，理解它们才能写出既正确又高并发的写入逻辑。
逻辑备份 + 物理备份 + binlog 组合，主从复制兜底，定期做恢复演练。备份不是目的，能恢复才是。
读写分离、MHA 切换、分库分表是规模化演进的必由之路。先缓存、再读写分离、最后才分库分表，按节奏演进而不是一步到位。
很多老教程还在对比两种引擎，但现实中答案已经非常明确。用一个表看清差异：
| 对比项 | InnoDB（推荐） | MyISAM |
|---|---|---|
| 事务支持 | 支持，ACID 完整 | 不支持 |
| 锁粒度 | 行级锁，并发高 | 表级锁，写入互斥 |
| 崩溃恢复 | redo log 自动恢复 | 易损坏、恢复困难 |
| 外键 | 支持 | 不支持 |
| 典型场景 | 绝大多数业务系统 | 只读报表、全文检索等边缘场景 |
下面每一条都是线上事故换来的经验，照着做能避开绝大多数数据库大坑。
订单、商品、库存的强一致性依赖事务，MySQL 的 ACID 保证每一笔交易都不出错。
文章、评论、用户体系用 MySQL 存储，配合缓存轻松支撑百万级访问。
ERP、CRM、进销存等内部系统，MySQL 是成本最低、最稳的选择。
对一致性与可靠性要求高的账务数据，事务 + binlog + 高可用让数据有据可查。
