MySQL架构设计课｜源码级优化+高可用方案（数据库调优+主从复制实战）

这门课的名字里有两个词容易让人误判：「架构设计」和「源码级」。前者听起来像给 DBA 准备的，后者听起来像要啃 C 语言。但实际看下来，它更接近一门「后端开发在真实工作里会遇到的 MySQL 问题合集」——主从延迟怎么查、复制断了怎么修、故障切换选哪个方案、慢查询为什么改了索引还是慢。如果你平时写业务代码，但数据库一出问题就只能找运维，这门课值得花时间。

它解决的是哪些具体场景

不是从建表语法讲起，而是从「已经上线、正在跑」的状态切入。典型的几类工作场景：主库压力大，想加从库分担读流量，但不确定二进制日志该用哪种格式、日志点复制和 GTID 复制该选哪个；从库数据对不上主库，不知道是延迟还是真丢了；线上主库挂了，需要有人能在几分钟内完成切换而不是干等。课程里关于复制原理、MHA / MMM 这类方案的对比，都是在回答这些问题。另外一部分是调优：执行计划怎么看、索引为什么没走上、SQL 改写从哪下手。

学完能独立做什么

比较现实的预期是：能自己搭起一套一主一从（或多从）的复制环境，看懂复制状态里的关键字段，判断延迟出在哪个环节；能根据业务对可用性的要求，说明白为什么这个场景选 MHA 而不是 MMM，或者为什么干脆上 MaxScale 做中间件层；面对一条慢 SQL，能走完「看执行计划 → 判断索引问题 → 改写或加索引 → 验证」这个流程，而不是凭感觉加索引。故障切换的实操部分能让你在演练环境里跑一遍完整流程，知道切换时哪些数据可能丢、哪些配置容易踩坑。这些能力对应的是「能独立处理中小规模 MySQL 的日常运维和调优」，不是「能设计超大规模分布式数据库」——后者靠一门课解决不了。

架构方案的取舍是重点

高可用这部分没有停在「怎么配」，而是花了篇幅讲优缺点。MHA 的切换逻辑和它的局限、MMM 的双主模式在什么情况下会出问题、MaxScale 作为代理层引入后多出来的复杂度和收益，这些对比比配置步骤更有价值。因为实际选型时，难的不是把方案跑起来，而是判断当前团队和业务规模配不配得上这套方案——人手不够时，上一套需要专人维护的架构反而是负担。课程里这类判断的素材给得比较足。

资料适合什么基础

需要你已经会写基本的 SQL，知道什么是索引、什么是事务，最好在真实项目里用过 MySQL。完全没接触过数据库的人听起来会吃力，因为课程默认你理解「主从」「读写分离」这些词指的是什么。反过来，如果你已经在用 MySQL 但一直停留在「会写查询」的层面，想补齐复制、高可用、调优这几块，匹配度比较高。源码级的部分属于加深理解，跟不上不影响主线，可以先跳过，等实际遇到问题时再回头看。

怎么用这份资料

建议不要按顺序从头看到尾。先确认自己当前最痛的点：如果是查询慢，直接看调优和执行计划相关的内容；如果是读写分离和故障切换，从复制原理看起，再看架构方案对比。每看完一个方案，最好在本地或测试环境动手搭一遍——高可用的东西光看视频记不住，切换流程必须自己跑过才有感觉。源码和原理部分当作查阅资料，卡住的时候再回去看。