Epilogue Let's Build a My SQL Knowledge Network Online Together

Epilogue - Let’s Build a MySQL Knowledge Network Online Together #

Time flies, and this is the last article of this series. Looking back at the whole process, if I had to describe it in one word, it would be “unexpected”:

I didn’t expect the articles to be so challenging to write, as it seems like every article required me to use all my knowledge;

I didn’t expect the comments to be so fantastic, to the point where I spent as much time in the comments section as I did on the main content;

I didn’t expect to gain so much from this experience, every time I was questioned in the comments section, it excited me to analyze the code with a long-lost enthusiasm.

If I were to evaluate this column myself:

The part I am most satisfied with is that every article comes with practical examples and tries to explain the principles as clearly as possible;

The paragraph I am most proud of is when I rewrote the article on transaction isolation levels for the third time and finally was able to say, “Here, we have connected consistency read, current read, and row locks together”;

The happiest moment for me is when I see classmates in the comments section accurately using the knowledge points introduced in the previous articles to answer the post-lesson questions. Because the way I understand building a knowledge network is going from point to line, from line to network, and from network to surface. I am delighted to have been able to go through this process together with everyone.

Of course, I value your feedback the most. So when I see you saying “good” in the comments section and on Zhihu, I will only design the content and post-lesson questions in greater detail.

At the same time, I know that among the subscribed readers of this column, there are newcomers who have just started learning MySQL and there are also students who have been using MySQL for many years. So, I always remind myself to try my best to make sure everyone gains something from these articles.

In my understanding, articles introducing databases need to be practical, with each operation having its corresponding principle, and each principle having its own underlying principle. This is a chain. Being able to explain one link in the chain clearly may make a good article. However, each layer has different audiences. Therefore, the goal I set for these 45 articles is to explain the operations and the first layer of principles clearly while touching on the second layer of principles where appropriate. I hope such a design won’t make you feel that it’s too shallow.

Some students have been asking about the learning path for MySQL, and here I will share my understanding with you.

1. There are countless paths, but practice comes first #

If you ask a DBA about the knowledge point they understand the most deeply, they will most likely tell you it is the pit they have fallen into the deepest. This illustrates the importance of “practice”.

When I used to train newcomers, the first step I asked them to take was to manually set up a master-slave replication structure. And when they encountered problems, I required them to reproduce them by taking action.

From the comments in the column, it can be seen that many students are conducting experiments following the examples in the column. I think this is a very good habit, and I hope you can continue to stick with it. The same principle applies when reading other technical articles and books. If you think you understand a knowledge point, you must also try to design an example to validate it.

At the same time, I suggest that when designing examples, you also design a contrasting counter-example, in order to achieve the seamless integration of knowledge. Just like in the process of writing this column, I feel that I have also gained a lot of knowledge, mainly thanks to the process of designing examples for the articles.

2. Principles are hard to explain, but your efforts won’t be wasted #

Whether it’s practicing first and then understanding the principles, or understanding the principles first and then verifying them through practice, both methods are good ways of learning, and their effectiveness varies from person to person. However, how can you prove that you really understand the principles? The answer is to speak or write about them.

If someone asks you about a certain knowledge point, it’s great because you should make sure to explain it clearly to them. Don’t think that it’s a waste of time. By doing so, you can not only verify that you have indeed understood the knowledge point, but also improve your technical communication skills. After all, you will eventually have to explain principles to three types of people: your boss, the evaluators in promotion interviews, and the interviewers in new job interviews.

When I mentor newbies, if there are more than one in the same group, I ask them to form a study group and regularly give them a question that already has a definitive answer. They research individually and then discuss within the group. If you happen to encounter classmates who are willing to form a study group with you, treasure it.

“Writing it out” is an even higher level. Because, during the process of writing, you may discover that your “understanding” is likely just an illusion. Therefore, it is also a good method to solidify your learning achievements by writing down your understanding of the knowledge points under the article.

3. Lack of Systematic Knowledge, Forget with a Turn #

One benefit of “writing down” knowledge points is that you will discover the associated knowledge points. Delving deeper, dots connect to form lines, and then you can find intersections with other lines.

For example, in our column, we discuss the non-logging operations on temporary tables, and then you can ask yourself a question: does this lead to potential synchronization errors in the standby database? Another example is understanding the behavior of temporary tables under different binlog formats, and then asking yourself a follow-up question: what would happen if a table is initially created in statement format and later modified to row format (or vice versa)?

Once you understand all of this, you will be able to link temporary tables, log formats, replication mechanisms, and even transaction mechanisms.

I believe that, like me, you also love these moments of intersection during the learning process. As intersections increase, they form a network. With a network in place, the speed at which you absorb new knowledge becomes faster.

For example, if you have a clear understanding of transaction isolation levels, when you come across the article in the 45th section that talks about how exceeding the max_trx_id can result in continuous dirty reads, I believe you will easily grasp the concept.

4. Completing the Manual and Clarifying Points with Examples #

Some students have asked me if they should start by reading the manual. My suggestion is not to. The time to read the manual should be when your knowledge network is already well established.

You may ask, what does it mean to have a well-established knowledge network? Actually, there is no fixed standard for this. However, there are some basic practices that can help you evaluate it.

  • Can you explain the meaning of each line in error logs and slow query logs?
  • Can you quickly assess whether a table structure or an SQL statement is well-designed?
  • Can you “mentally execute” the entire execution process based on the results of “explain” (we have practiced this a few times in this column)?
  • Analyze each piece of advice on MySQL found on the Internet:
    • If you find it unreasonable, can you give your opinion?
    • If you find it reasonable, can you provide your own explanation?

Then, how do you judge whether your opinion or explanation is correct? The quickest and most effective way is to discuss with experienced people. For example, leaving a comment in the comment section of our column’s related articles is a feasible method.

After completing these practices, you should have more confidence in yourself. At this point, you can go back to the manual, fill in the blind spots in your knowledge network, and form a complete understanding. The method to achieve this is to combine theory with practice, as mentioned in the first two points.

I hope that these 45 articles can serve as an accelerator in the process of building your MySQL knowledge system.

I intentionally arranged the discussion of the different behaviors after reaching the defined limit of various auto-increment IDs in MySQL as the last article. “45” represents the ID limit of this column, and this concluding statement is the first value after exceeding the limit. This value is undefined, and it is up to you to define it:

  • Some students may choose to treat it just like the auto-increment ID defined for tables and let it remain here.
  • Some students may choose to review and replace their previous understanding with a new and more comprehensive understanding.
  • Perhaps the most common strategy is to mark the articles that have been thoroughly understood, like the thread_id, and specifically review those articles that were previously read but are now vaguely remembered.

Regardless of which strategy you choose, as long as a few knowledge points in these 45 articles persist in your knowledge network, just like Xid or InnoDB trx_id, the time you and I have spent here will be “geek time” and will be worthwhile.