Mysql source code learning-eight degrees Space

 

After learning the lexical analysis and syntax analysis, I started my formal learning tour of Mysql source code. How many modules can we start ?! Fortunately, I found a module division from the internet. I will try to track the source code step by step based on this module to unveil Mysql.

<Script> </script>

 

 

From the top down, we can see the division of each module. First, the client sends a request to connect to the server. Through the connection manager module, the connection management module calls the Thread Manager module, that is, the Thread management module, here we will create a new thread for a connection and specifically serve this connection. This ensures that each connection has an independent thread for its work, of course, there is usually a limit on the number of connections, otherwise there will be no limit to creating new threads, and the operating system will not be able to withstand it. Next we enter the User Module, the User Module, which should be in the identity authentication phase. To put it bluntly, we should check the User name and password, and of course also include permission checks (only self-access control is required, unlike Oracle, Mysql does not support role, not to mention label. This is simple but not simple, ^ _ ^ ).

 

The above three modules are the stages that must be experienced during the login process. Connection manager creates a connection between the client and the server. thread manager allocates an independent thread for the new connection, and the user Module performs identity authentication. Oh yeah ~~

 

Next, enter the Commander Dispatcher module. The command distribution module is probably a switch case process. Different operations are performed according to different commands. This Module is indirectly associated with the Query Cache Module and the Logging Module, that is, the Query Cache Module and the log Module. The Query Cache module personally feels that it contains at least the result set Cache module. As for the execution plan Cache, This is not clear and you need to go to the source code. The Logging Module is the legendary log. Logs include redo and undo. The log system is a database and an important means to implement transaction features, transactions are the fundamental difference between database and file system. Don't underestimate the Logging Module !!

 

The command distribution module distributes commands to different sub-modules based on the command nature. SELECT is allocated to Optimizer, which is the optimization module. The most important thing about a select statement is the execution plan. A good execution plan is twice faster than a bad execution plan, this is why we need to create an index. In fact, we need to create a secondary index on the columns that are frequently queried to change the execution plan and enable the execution plan to select a secondary index, instead of dropping clustered indexes (of course, clustering indexes are fundamental ). UPDATE, INSERT, and DELETE are handed over to the Table Modification Module. If you do not know, this Module mainly processes data updates (the UPDATE mentioned here is the change of index data, that is, UID ). The Repairs is assigned to the Table Maintenance Module, which literally means that the Table Maintenance Module is OUT. The default Table is broken and can be repaired? What's wrong? I don't know much about it .... Replication is assigned to the Replication Module. The last one is that Status is assigned to the Status Reporting Module, which I seem to have been involved in. Are these dynamic attempts? For example, to check the usage of lock resources in the current state of the system, this module should be an essential module for performance analysts to travel at home. Through this module, the bottleneck of system performance may be quickly found.

 

The above modules go to the Access Control Module. The Access Control Module does not contain Access Control ..., This access control is a simple DAC, that is, whether the user has the permission to add, delete, modify, and query the object to be accessed. Next, go to the Table Manager module. because Mysql supports different storage engines, and this module is a unified module, I personally think this should be the dictionary object management module of the Table, that is, some metadata of the table, such as the columns contained in the table, the type of each column, the creator of the table, the creation date, and the storage engine of the table. The Abstract Storage Engine Module is the Abstract Storage Engine Module. Mysql maintains so many Storage engines on the server at the same time, it is implemented through a handler abstract class (I don't know the concept of an abstract class on wood, but I 've been missing C ++ and JAVA for a long time ...), Each storage engine implements a specific handler class according to the specified interface, and then calls the class based on the information of the storage engine in the Table Manager module above, select the corresponding handler class to perform physical operations on the corresponding table.

 

After reading this module diagram, I feel a lot clearer. Next we will learn each module step by step. Of course, these modules are also a process of sequential execution of the execution process. I wrote this article today. Next time I will start to learn the first module: Connection Manager.

 

PS. It seems that I am not so busy recently. It is a little easier to work overtime for several months. In the future, we will spend more spare time studying books.

 

PS again. My mind is full of porridge every day after work. When I come back to write a blog, I want to relax. The title space is JAY's album name. This is a metaphor for Mysql's modules ^_^

 

Excerpted with no code in mind