Hatena::ブログ(Diary)

ablog このページをアンテナに追加 RSSフィード Twitter

2018-03-25

MySQL のストレージエンジンとのインタフェース

どの当たりのコードか当たりをつけ中。


  • Interaction of the Core Modules
    • Figure 1-1. High-level view of MySQL modules

f:id:yohei-a:20180325184159p:image:w360

ABSTRACTED STORAGE ENGINE INTERFACE (TABLE HANDLER)

This module is actually an abstract class named handler and a structure called a handlerton. The handlerton structure was added in version 5.1 for plug-in integration. It provides a standardized interface to perform low-level storage and retrieval operations.

The table hander is defined in sql/handler.h and partially implemented in sql/handler.cc. The derived specific storage engine classes will have to implement all the pure virtual methods of this class. It will be discussed in greater detail in Chapter 9.

This module was introduced in version 3.23 to facilitate the integration of Berkeley DB tables. This move had far-reaching consequences: now a variety of low-level storage engines could be put underneath MySQL with a fair amount of ease. The code was further refined during the integration of InnoDB. The future of the module will largely depend on what new storage engines will be integrated into MySQL, and on the way the existing ones will change. For example, sometimes a new feature in some underlying storage engine may require an addition to the abstracted interface to make it available to the higher-level modules.

Shared Aspects of Architecture

While there is a great degree of freedom in the implementation of a storage engine, all storage engines must integrate with the main MySQL server code. As a result they have a few things in common. Aside from having to support the basic concepts of tables residing in a database, records, columns, keys, read and write operations, and other aspects stipulated by the storage engine interface requirements, each storage engine also inherits the features and properties from the core table manipulation code. In other words, they get some functionality and architecture regardless of whether they need it.

Regardless of the storage engine, all tables have one .frm file per table containing the table definition with the column names, their types and sizes, key information, and other table properties. A .frm file in essence gathers and stores the information from CREATE TABLE. Up until version 5.1 the filename was always the same as the name of the table, and it resided in a directory corresponding to the database name. Version 5.1 introduced a change. The table and database name are now encoded in build_ table_filename( ) in sql/sql_table.cc. Code reads and parses the files using openfrm( ) from sql/table.cc, and writes to them using create_frm( ) from the same source file.

Regardless of the storage engine, the server reads the table definition from the .frm file, and stores it in what is called a table cache. This way, the next time the table needs to be accessed, the server does not have to reread and reparse the .frm file, but rather can use the cached information.

MySQL server utilizes the mechanism of table locking. Thus, each storage engine can either take advantage of this feature, or politely ask the table lock manager to always grant a write lock, which bypasses the core code table locking. In that case, the storage engine itself becomes responsible for ensuring consistency during concurrent access.