The Storage Engine Interface — Chapter 7
In continuation to below post
MySQL provides a layer of abstraction that permits different storage engines to access their tables using the same API. In the past, this interface was called the table handler. More recently, the term storage engine was introduced. In the current terminology, the storage engine refers to the code that actually stores and retrieves the data, while the table handler refers to the interface between the storage engine and the MySQL optimizer.
The interface is implemented through an abstract class named handler, which provides methods for basic operations such as opening and closing a table, sequentially scanning through the records, retrieving records based on the value of a key, storing a record, and deleting a record. Each storage engine implements a subclass of the handler, implementing the interface methods to translate the handler operations into the low-level storage/retrieval API calls of that particular storage engine.
Adding a Custom Storage Engine to MySQL
There are a number of reasons for adding a custom storage engine to MySQL:
• You have a legacy, proprietary database and want to give it an SQL/ODBC
interface.
• You have some very specific requirements in the areas of performance or data security that are not being met by any of the existing storage engines.
• You have created a low-level data storage and retrieval module that you believe will rule the world, but you do not want to (or are not able to) write an SQL optimizer to go with it.
• Your proprietary SQL optimizer does not meet your needs, and you want a better one for your storage engine.
• You just want to learn more about MySQL internals.
This chapter consists more about how to implement a storage engine, but that wasn’t my requirement. I am just going through this book so that I can understand the basic functioning of MySQL and it will be helpful in my interviews.
For understanding the implementation you can refer from book yourself.
Reference
