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.
Let us illustrate with an example. Our storage engine will provide a read-only SQL interface to comma-separated value (CSV) text files. In version 4.1 and earlier, storage engine integration requires a lot of source modifications. It has become much cleaner in version 5.1. If you are writing a custom storage engine, depending on your needs, you may choose to lean toward a more mature code base (4.1), or go with what (at the time of this writing) is the bleeding edge (5.1). I will provide instructions for versions 4.1 and 5.1. For the sake of brevity, I will not provide instructions for other versions of MySQL. Those who need to integrate their storage engine into other versions are advised to search (case-insensitive) for the string "blackhole" in the source tree of the given version, and follow the patterns ...