Mysql source code analysis (6): Plugin architecture introduction (continued)-reprinted

Document directory

• Myisam Initialization
• Open a table

In the previous article, we analyzed the plug-in interface of Mysql and the initialization process of plug-in. Here we continue to see how plug-in is used. The problem is basically solved through examples. It mainly analyzes how myisam is called through the plugin interface.

Myisam is the earliest and default storage engine of mysql. We also saw that myisam is first initialized during plug-in initialization before other storage engines are initialized. Here we assume that you want to operate on a myisam table and take a look at the call process involved in it.

Myisam Initialization

The definition of myisam plugin can be found in storage/myisam/ha_isam.cc:

Mysql_declare_plugin (myisam)

{

MYSQL_STORAGE_ENGINE_PLUGIN,

& Myisam_storage_engine,

"MyISAM ",

"MySQL AB ",

"Default engine as of MySQL 3.23 with great performance ",

PLUGIN_LICENSE_GPL,

Myisam_init,/* Plugin Init */

NULL,/* Plugin Deinit */

0x0100,/* 1.0 */

NULL,/* status variables */

NULL,/* system variables */

NULL/* config options */

}

Mysql_declare_plugin_end;

The initialization function is myisam_init. As mentioned in the previous article, the storage engine plug-ins are all initialized through ha_initialize_handlerton. The input parameter of myisam_init is void * p, which is actually handlerton *. Handlerton encapsulates an interface required to access a storage engine in mysql. Each storage engine has a handlerton object in the global space and stores it in the data domain of the plugin structure in the corresponding memory. The specific definition of this structure can be found in SQL/handler. h. Myisam_init is easy to do. It sets the various domains in handlerton. The most important domain is create, which is directed to a function myisam_create_handler. This function is used to create handler and operate database files.

Open a table

The data base table is the basis for all operations in the database. Let's take a look at what to do to open a table. When a select command comes in, execute_sqlcom_select in SQL _parse.cc is executed, and all the tables used for this command are passed in to parse. It calls open_and_lock_tables to open the specified table, calls open_and_lock_tables_derived, calls open_tables, and CALLS open_table (SQL _base.cc ). Open_unireg_entry is the first thing to do after a lot of calls. Its name is very strange, but it does start to open the table. We will take a closer look at this function and the function it calls. This function is very long. In fact, most of them are error processing. The most important is the following lines:

Static int open_unireg_entry (THD * thd, TABLE * entry, TABLE_LIST * table_list, const char * alias, char * cache_key, uint cache_key_length, MEM_ROOT * mem_root, uint flags ){

...

Share = get_table_cmd_with_create (thd, table_list, cache_key, cache_key_length, OPEN_VIEW | table_list-> I _s_requested_object, & error );

Open_table_from_share (thd, share, alias ,...);

...

}

Get_table_cmd_with_create is to create a table_share structure, including the data structure shared by tables of the same type. open_table_from_share opens the corresponding table to be operated through this public structure.

TABLE_SHARE * get_table_share (THD * thd, TABLE_LIST * table_list ,...){

Share = alloc_table_share (table_list, key, key_length); // allocate memory

My_hash_insert (& table_def_cache, (uchar *) share); // you can directly use

Open_table_def (thd, share, db_flags); // specifies the definition of the table on behalf of which the frm file needs to be read.

}

Open_table_def is used to open a file that Stores Table definitions. In mysql, each table has a. frm file that stores the definition of the table. This function is used to open the frm file corresponding to the table, read the definition information, and fill in the TABLE_SHARE structure.

Int open_table_def (THD * thd, TABLE_SHARE * share, uint db_flags ){

File = my_open (path, O_RDONLY | O_SHARE, MYF (0 ))

Open_binary_frm (thd, share, head, file );

}

Open_binary_frm reads binary frm file information. This function is too long, but we are only interested in the plug-in. Because the storage engine information of each table is read from the frm file, let's look at the relevant code snippets:

Open_binary_frm (...){

...

Plugin_ref tmp_plugin = ha_resolve_by_name (thd, & name); // name is the name of the storage engine, such as "myisam ". Find the plugin according to the name.

Share-> db_plugin = my_plugin_lock (NULL, & tmp_plugin); // Save the reference of plugin for future use. The "data" field in plugin is handlerton *, which is the main entry to use plugin.

...

}

Okay, TABLE_SHARE is set. Let's go back to open_unireg_entry and continue to check open_table_from_share. This is where the table is actually opened. This function is still in SQL/table. cc. This function is too long... fortunately, we just want to focus on plug-in-related content. The TABLE has a file structure and the type is handler *. As we mentioned before, handler is an Open TABLE reference. Obviously, one of the responsibilities of open_table_from_share is to set this field.

Int open_table_from_share (THD * thd, TABLE_SHARE * share,... TABLE * outparam,...) {// outparam is the information of the opened TABLE.

...

Outparam-> file = get_new_handler (share, & outparam-> mem_root, share-> db_type (); // go straight to the topic and get a handler. Share-> db_type () returns the handlerton corresponding to plugin, which is to forcibly convert plugin-> data to handlerton.

...

Outparam-> file-> ha_open (outparam,...); // call the handler-defined open function of plugin to perform custom open operations.

...

}

Get_new_handler is responsible for constructing a handler object based on TABLE_SHARE content. This function is in SQL/handler. cc.

Handler * get_new_handler (TABLE_SHARE * share, MEM_ROOT * alloc, handlerton * db_type ){

File = db_type-> create (db_type, share, alloc); // call the create function of plugin to create a handler member.

File-> init ();

}

As mentioned above, the create FUNCTION corresponding to myisam is myisam_create_handler. This function is a new ha_myisam object, and ha_myisam is inherited from handler and the handler function is overloaded.

In this way, the handler of the database table file can be used. Its first use is to be called ha_open in open_table_from_share. Ha_open is defined in handler. cc. It is actually the number of open letters after the overload is called. In ha_myisam, we can see the definition of the open function. Here we will not look at it carefully. The implementation details are related to the file structure of myisam.

The following figure shows how to open the table in the SELECT * from test statement. The main process includes:

• Find the name of the storage engine from the frm file and obtain the handlerton of the corresponding storage engine plugin.
• Call the create function of handlerton to generate handler.
• Open the table file through the handler overload open function

It is clear.

Here, we have the table handler. In the future, all operations involving the storage engine will be called through this interface. In this way, the storage engine plugin is closely integrated with the mysql core, various departments perform complex SQL operations together.