师从前阿里技术专家丁奇，我是如何提升MySQL的？

出处：极客时间《MySQL 实战 45 讲》

对于做后端的同学，MySQL 是绕不过的一道“坎”。前阿里资深技术专家丁奇在极客时间开了《MySQL 实战 45 讲》专栏，内容覆盖从原理到实战，非常受欢迎。今天，给你分享几个专栏用户故事，希望他们的学习经验和方法，对你的 MySQL 学习之路有所帮助。

我是一名有着十多年开发经验的程序员，喜欢技术，热爱编程，现在北京特微智能科技有限公司工作，担任北京软件研发部经理。

本人工作中使用 MySQL 快 10 年了，OLTP 与 OLAP 都做过，看过很多 MySQL 的书，自我感觉对 MySQL 还算熟悉，所以最初看到《MySQL 实战 45 讲》的目录时，并没有太多感觉，就是些常见问题嘛。但是，出于对极客时间课程质量的信任，我还是买了，就当是查缺补漏。

但是，文章更新出来后，可不得了，虽然目录没什么出奇之处，但内容的组织方式却完全不同于其他书籍和课程：以实际问题驱动，讲解深入浅出、生动有趣，帮我重新梳理了 MySQL 的知识体系，进而使得我在实际使用 MySQL 的过程中更加得心应手。

因为自己的知识体系更加完整了，所以在生产环境中出现问题的时候，我可以更加冷静的去思考，直奔问题本质，不再是各种盲目试错。这，也算是我学习这个专栏的最大收获吧。就比如说：

第 24 讲 | MySQL 是怎么保证主备一致的？

第 25 讲 | MySQL 是怎么保证高可用的？

第 26 讲 | 备库为什么会延迟好几个小时？

第 27 讲 | 主库出问题了，从库怎么办？

第 28 讲 | 读写分离有哪些坑？

第 29 讲 | 如何判断一个数据库是不是出问题了？

不仅解释了我们之前出现备库延迟的原因，也让我对我们后续要采用的数据库高可用架构更有信心，对我的帮助非常大。

总的来说，这门课程是有深度的，初级工程师第一遍应该会看不太懂，但是一旦看懂了，对 MySQL 的理解就会有质的飞越。以我的经验来看，搞懂这 45 篇文章的知识点，你的 MySQL 水平会超过 80% 的高级工程师。所以，我也希望处于技能徘徊阶段的上进青年能早些学习这门课程，对自己、对团队、对公司来说都有莫大的好处。

最后，还得称赞一下极客时间课程的质量。以前在别的平台上听过很多课程，突出的问题就是老师讲课废话多、口语不断，各种无用的“嗯”“啊”，各种没有意义的重复，这不是学习，而是遭罪，往往听着听着就走神了，再回过神时，关键知识点已经讲完了。而极客时间上的课程，讲述流利、内容也都是经过认真打磨的，听课时给我的感觉就是非常过瘾，现在在上下班路上、在堵车时，再也不会感到焦躁不安了。

小编提示：《MySQL 实战 45 讲》限时 24 小时拼团¥79，原价¥99，已有超过 2.8w 人加入学习，想认真进阶 MySQL 的同学，请抓紧搭上这趟快车（方式：扫上图二维码）

我是一名即将毕业的硕士，专业是电路与系统，方向是信息对抗，实验室主要的工作内容是雷达系统设计和电子战相关的算法研究。校招的时候，因为我对信息对抗领域的兴趣不大，因此找了 Java 开发工程师的工作。

在这个跨专业的过程中，我开始自学计算机专业的基础知识，数据结构与算法以及计算机网络的部分学习其实并没有难度，但是数据库就不太不一样了。我看了不少数据库的资料，脑海中充斥的都是零散的理论和大量的命令，但是对数据库的认识却一直停留在简单应用的层面，而对于底层是如何支持以及实现这些命令等问题却并不清楚。

也就是说，我面临的问题是，虽然摄入了大量知识，但是无法利用这些知识构建起稳固的大厦。而我也明白，我缺少的是实战的磨练与系统的知识结构。

《MySQL 实战 45 讲》专栏，解决了我的很多疑问。以「第 04 讲 | 深入浅出索引（上）」和「第 05 讲 | 深入浅出索引（下）」为例，林晓斌（丁奇）老师从索引的常见模型出发，介绍了常见的数据库引擎可用的 3 种数据结构，从使用的角度介绍了三种数据结构的优缺点，并通过实例分析了三种数据结构选择的原则，以及索引模型在数据库问题分析中的重要作用。这个分析，让我意识到了索引模型或者说底层数据结构对于数据库的意义。

接着，老师以 InnoDB 为例分析了它的 B+ 树结构以及选择 B+ 树的原因，并且引出了主键索引和普通索引的区别与选择原则，让我对这些常见的索引以及索引的选择有了一定的认识。

在这个实例的基础上又分析了索引在数据库引擎中是如何维护的，从性能和存储空间的角度分析了自增主键和业务逻辑字段做主键的应用场景。这个分析让我认识到了数据库索引的选择其实还是取决于业务场景与底层逻辑的匹配性。

接下来，深入地讨论了数据库索引相关的概念，包括覆盖索引、前缀索引、索引下推这些概念，分析了不同的索引出现的价值和意义。通过具体的实例分析了不同的查询语句背后所使用的索引，从索引的搜索次数（即性能）以及空间 2 个方面分析对比了不同的业务场景选择索引的原则。总结一下，在满足语句需求的情形下，尽量少地访问资源是数据库设计的重要原则之一。

其实，从这 2 篇文章中，我学习到的不止是书本中的数据库相关的知识，更重要的是建立起了数据库学习中“理论 - 实现 - 应用 - 问题 - 解决 - 精进”的学习闭环，帮助我一步步地建立起自己的知识结构。这个非常重要，因为完整的知识结构能够赋予我举一反三和解决问题的能力，而不再是简单的 CRUD。

所以，我觉得这个专栏，也特别适合我这种已经接触了大量的数据库资料，但还没建立起自己的知识网络的同学们。

我是一个普通的九零后技术男，从事后端开发工作五年多了，现在是一名小主管。

2018 年的时候，我正处于瓶颈期。我深知自己的短板就是基础知识不够扎实，有焦虑，也有求知欲。就在这时，极客时间走入了我的世界。我目前已经订阅了 14 个专栏，有的已经学完了，有的正在学。

脚踏实地地学习，让我不再那么焦虑、彷徨。而在系统性地学习专栏的过程中，我确实在架构设计、网络协议、数据结构、数据库等方面有了更深入的理解，也逐渐度过了瓶颈期。

说到我学习《MySQL 实战 45 讲》专栏的最大收获，就是对数据库的底层执行过程更了解了，然后我就能够从另一个维度去观察它了。

比如以前，我不知道一条 SQL 语句在数据库中是如何运行的。而现在，我经常会脑补一条 SQL 语句在连接器、查询缓存、分析器、优化器、执行器、存储引擎的执行流程，如下图。

再比如，「第 16 讲 | “order by”是怎么工作的？」，讲的是关于 order by 的内容。

大家都知道 order by 是用来排序的，但它是如何执行的？用到了什么排序算法？如何优化大数据量排序很慢的问题？

学到这节课后，以上问题我都回答出来了。我在学完这篇文章以后，也整理了自己的思维导图，这个整理过程又加深了我的理解。

还有一个让我感触特别深的案例，有一次我在工作上遇到了一条复杂的 SQL 语句执行很慢的问题，200 万的数据量居然要执行好几分钟。之后，我用 sql server profiler 查看执行计划，原来是进行了全表扫描。

这些数据的特点是，查询多、修改少。所以，我在给 where 条件的一个字段加了索引后，执行计划从全表扫描变成了索引扫描，扫描行数降低到 50w，速度快了一个量级。

顺便说一下，添加索引有利有弊，要综合考虑。学完「第 11 讲 | 怎么给字符串字段加索引？」后，你就知道如何用好索引了。

这里，我也顺便和你分享几个我在学习中用到的软件：

1. Forest（一款番茄工作法的软件，25 分钟一个周期），用来专注学习。

2. XMind（一款思维导图软件），用来做笔记，方便复习。

3. Anki（一个记忆神器），用来记忆，制作 Anki 卡片后，可以通过问题、想答案、对答案。

最后，学习没有捷径，只能一步一个脚印、死磕一个又一个的知识点。就像陈皓老师在《左耳听风》中说的：

小编提示：《MySQL 实战 45 讲》限时 24 小时拼团¥79，原价¥99，已有超过 2.8w 人加入学习，想认真进阶 MySQL 的同学，请抓紧搭上这趟快车（方式：扫上图二维码）

我是一名来自深圳某互联网金融公司的后台开发小哥，每天都会跟数据库打交道。在遇到《MySQL 实战 45 讲》之前，虽说写了三年的业务代码，但对 MySQL 无太多深层次的认识，只停留在 CRUD 层次，能满足业务逻辑就万事大吉。我甚至不知道索引为什么能提高查询效率。

对 MySQL 知识的匮乏，导致我平时总是回避与同事讨论 MySQL 相关的问题。现在回想，以前自己也犯过很多错：

1. 主键使用 UUID，非自增主键；

2. 联合索引内的字段顺序随意排放；

3. 滥用索引，创建尽量多的索引来提升查询效率；

4. 不管 SQL 语句是否合理，只要能返回结果集就是好 SQL。

学习专栏后，现在每天看到数据库和 SQL 语句，我想的最多就是锁、索引和事务。

现在我在设计表结构时，会根据业务反复推敲每个索引的合理性。这时，我的大脑里总是会浮现出一棵棵的索引树，在所有索引树上将业务逻辑走一遍。就像小说里的武林高手看到对手的招势时，早已在大脑里演练完了所有招势，保证一招制敌。

我也经常在办公室听同事们讨论联合索引的最左前缀原则：通过 name 字段查询，可以走这个联合索引，因为 name 字段是联合索引的最左字段。如果遇上更热心的同事，会在纸上给你罗列出所有索引的情况，如联合索引 (A, B, C)，包含了下面这些索引：(A)、(A,B)、(A,C)、(A,B,C)。

看他说得头头是道，感觉真是这么一回事，然后我自己也就记下了排列组合的公式。下次再遇上这种情况，照猫画虎，不管结论是否正确，肯定可以唬住对方。

学习专栏后，我才发现上述解释是不正确的。当你知道了联合索引是一棵 B+ 树，叶子内容按照字段顺序排列以后，就已经掌握了最左前缀原则：最左前缀除了可以是联合索引的最左 N 个字段，也可以是字符串索引的最左 M 个字符。

除了上述最左前缀原则的认识有所偏差外，对模糊查询是否走索引，也存在不恰当的认识：模糊查询不走索引，所以查询速度特别慢。针对这种情况，我来举个例子说明一下索引使用问题：

大部分同学会认为前面 2 种情况（'j'或'j%'）可以使用索引，而最后 2 种情况（'%j'或'%j%'）不能使用索引。理由很简单也很有力：索引是用来提高查询的效率的，如果后面 2 种情况使用了索引，那为啥它们的查询速度这么慢。

这种解释看起来挺有道理的，但说法是不正确的，原因在于没弄明白“用索引”和“用索引快速定位记录”的区别：

1. like 'j' 或 'j%' 可以使用索引，并且快速定位记录，表象就是查询速度很快。

2. like '%j' 或 '%j%'，只是在二级索引树上遍历查找记录，并不能快速定位（使用了索引，但是扫描了整棵索引树），表象就是查询速度没那么快。

如果说某一篇文章让我觉得特别有用的话，我推荐「第 18 讲 | 为什么这些 SQL 语句逻辑相同，性能却差异巨大？」

文章分享了慢 SQL 中比较经典的三个案例，并对每种情况进行全面讲解和分析。当再遇到慢查询的问题时，我回忆起文章的知识，这些问题就能迎刃而解了。在平时开发中，我养成了通过 explain 来“脑补”一条 SQL 语句执行流程的好习惯，防止掉入隐式类型转换的陷阱，而带来不堪设想的生产事故。

通过学习专栏，我纠正了自己很多不正确的认识。现在我也会反复学习专栏中的每一篇文章，每次学习都有不一样的收获。

• 第一次：了解文章的各种概念，记录不理解的地方和疑问点，记录自己的对知识点的理解。

• 第二次：形成一个比较清晰的逻辑，对它的实现原理有了更深的认识，这次基本解决第一次学习时遗留的问题。

• 第三次：MySQL 的这种实现原理，是为了解决什么问题，带来的负作用。而未来自己做设计时，能否借鉴这种实现方式。

我也很喜欢丁奇老师的写作风格，老师会在文章开头抛出问题，接着开始讲解相关概念和剖析原理，然后引出工作中的应用场景，分析各种方案的利弊，最后总结和答疑。每次总被文章深深吸引，学习后让人回味无穷，意犹未尽。

除了丁奇老师的文章写得流畅清晰、通俗易懂之外，还有另外一个要大力推荐的是评论区。评论区卧虎藏龙，总能在评论区学习到文章以外的知识。每个评论老师都会认真阅读和回复，使得评论区特别活跃。

我非常感恩，跟着老师学习，让我体会到了学习是一件自然而又充满魅力的事情，也让我从一个基础不牢固的小白，一步步地充实了自己的知识库。另外，老师非常尽责，经常半夜回复和答疑，希望老师保重身体。谢谢！！

在《MySQL 实战 45 讲》中，丁奇会帮你梳理出学习 MySQL 的主线知识，比如事务、索引、锁等，还会就开发过程中经常遇到的具体问题和你分析讨论，并且帮你理解问题背后的本质。你会收获 MySQL 核心技术详解与原理说明和 36 个 MySQL 常见痛点问题解析。

最后，小编再提示下，《MySQL 实战 45 讲》限时拼团¥79，原价¥99，已有超过 2.8w 人加入学习，想认真进阶 MySQL 的同学，请抓紧搭上这趟快车（方式：扫下图二维码）

点击「阅读原文」，试读或立即拼团