本人服务端工程师，在学习这门课之前数据库一直是我的短板，曾听朋友说MySQL或数据库中涉及了很多方面的知识点，每一个拿出来展开讲几乎都能出一本书了，对数据库是越来越忌惮，同时也因为工作上并没有过多接触，水平便一直停留在编写简单SQL层面。
在面试中被问到数据库问题，只能无奈的说这块不太清楚，也曾在网上自学过，但网上的文章知识点比较零散，很多都是给出一些结论性的观点，由于不了解其内部原理，记忆很难深刻。
老实说，当初报这门课的时候就像买技术书籍一样，我相信大家都有这样的体会，以为买到了就等于学到了，所以有一段时间没有点开看过，以至于后面开始学的时候都是在追赶老师和大家的进度，唯一遗憾的地方就是没能跟老师及时留言互动。
这门课虽然是文字授课，但字里行间给我的感觉就是很亲切很舒服，为什么呢，因为老师可以把晦涩的知识变得通俗易懂，有时我在思考，如果让我来讲一个自己擅长的领域是否也能做到这一点，如果要做到的话需要什么样的知识储备呢。
最后真要感谢老师的这门课，让我从心里不再惧怕数据库问题，不管是工作还是面试中信心倍增，现在时不时都敢和我们DBA“切磋切磋“了，哈哈。
祝好~

不知道是最后一篇，否则的话就慢些读完了；
我是一名运维，公司也没有DBA，所以MySQL库也归我收拾；
读了老师的专栏，操作起数据库来，心情更好了；
老师的课，让我有了想看完《高性能MySQL》的兴趣；
听了老师的课，开发都来问我数据库的问题了，高兴；
老师你会有返场吗？我猜会 😄
可否透漏下接下来的安排，会有续集吗？进阶吗？
不想这一别就是一生。
您的从未谋面的学生。

我觉得是这样的，人的记忆是结构化的。

如果用纯文字做读书笔记，那么一段时间之后，再来看笔记，还得根据文字重建该结构。
倒不如直接看结构化的读书笔记，省去大脑再次重建的繁琐过程。

真是文不如表，表不如图，图不如动画啊。

下面是我的《MySQL实战》的PPT形式的读书笔记，如果想复习，就快速浏览PPT，就能快速重建记忆。
https://github.com/zhangkekf/reading-notes/tree/master/MySQL%E5%AE%9E%E6%88%98

目前才更新到了39小节，当然会持续更新，如果有时间会做成动画。再次感谢林老师！

菜鸟一枚才学浅
走马观花看专栏
一生运维甚可叹
点滴积累玩不转
老师功底很深厚
尔等求学莫欺骗
谦虚从容学知识
十年寒窗磨一剑
运维坎坷路漫长
风雨无阻永相伴
尔等成名归来时
扶摇直上亦无怨
感谢老师传知识
功德无量真佛现

感谢老师，课程受益匪浅，
课程结束后，如果有问题，是继续在这里的评论区提问，还是会有另外一条答疑通道？

另外，在第35篇我提了几个问题，老师还没有回答，我这里再贴一下，老师看一下
问题一：
对于BKA算法的流程理解，用文中的例子，先把t1表（小表）中查询需要的字段放入join_buffer, 然后把join_buffer里的字段值批量传给t2表，先根据索引a查到id，然后得到一批主键id，再根据主键id排序，然后再根据排完序的id去主键索引查数据（这里用到MRR）
理解是否正确？
这里对于主键id排序是在哪里做的，是在join_buffer里，还是另外再开辟一块临时内存？如果在join_buffer里，那join_buffer里的每行内容是不是：t2.id + t1查询必须的字段，并且join_buffer里是根据id排序的？

问题二：
虽然MySQL官方没有支持hash join，但是之前看到文章说，MariaDB已经支持hash join，能不能后续在答疑文章中简单总结下mariaDB支持的join算法

问题三：
在实际项目中，一个比较困惑的问题，看到过这样的类似写法：
select xxx from t1 join t2 on t1.id = t2.id for update （目的是获取几个表上最新的数据，并且加上锁，防止数据被更新）
这里有几个问题：
1) 像这样 join + for update，表上的加锁规则是怎么样的？是不是在需要join的两个表上根据具体的查询执行过程都加上锁？
2）像这样 join + for update 的用法是否合理？碰到这样的场景，应该怎么去做？

问题四：
看过阿里输出的开发手册里，强调 “最多不超过三表join”，实际项目中，给我感觉很难做到所有业务都不超过三表join，那这里的问题就是，有什么相关的经验方法，可以尽量降低参与join的数据表？
比如，在数据表里添加冗余字段，可以降低参与join的数据表数量，还有什么其他好的方法？

第一遍到今天就结束了，感谢老师的辛勤付出。
专栏的买的多，怕这个太长没时间学别的，也怕它太短让人意犹未尽。看评论的数量和质量，就能清晰的分辨一个专栏的优劣，老师的这个无疑是佼佼者中的佼佼者。
这个专栏学起来好像看《少年包青天》一样，
提出问题——谁是问题的凶手
分析问题——寻找问题的凶手
解决问题——找出问题的凶手
总结问题——记录抓住问题凶手的始末
真是精彩绝伦，我们程序员都是问题的终结者，发现问题、解决问题、总结问题是我们的责任。老师的指导，让我们的见识和技能得到了提升，这样便能解决更多的问题创造更多的价值。
而且我觉得技术的存在也是为了解决各种问题的，
数据库——解决数据存储的问题
WAL——解决数据一致性问题
多线程——解决性能差异的问题
锁——解决多线程并发导致数据不一致的问题
索引——解决数据查询或者操作慢的问题
日志——解决数据备份、同步、恢复等问题
数据库主备——解决数据高可用的问题
数据库读写分离——解决数据库压力的问题
数据库分库分表——解决数据量大的问题
从简单到复杂，解决一个问题就会引入一些新的问题，然后再想办法解决新的问题，事情就变得越来越复杂啦！但主体没变，附加值在一直增加，并且衍生出了许多新的东西，东西一多就需要分一下类，否则很难理解。所以，数据库按公司有分类，按存储引擎特点有分类，按功能特点有分类等等。
它的核心就是存储数据，剩下的就是怎么操作舒服怎么操作快的问题啦！想必其他工具也是如此？