My MySQL InnoDB Journey: From Interview to Six Years of Core Development

Interview Experience

In spring 2012, the author received a call from an Oracle recruiter and was invited to interview for a MySQL InnoDB kernel engineer position. The interview consisted of four rounds with the InnoDB manager Calvin, performance specialist Innam, storage‑engine veteran Marko, and architect Jimmy. The conversations were informal, focusing on past projects and understanding of database internals.

Team Structure and Culture

MySQL’s team hierarchy is very flat; even a junior engineer is only five levels away from Oracle’s founder. The InnoDB team at that time comprised eleven engineers from eight countries, including members from the United States, Finland, Australia, Canada, Sweden, India, Bulgaria, and China. The team members were seasoned database kernel developers, many of whom had previously worked on other storage engines such as Falcon or Sybase.

Work was largely remote, with daily tasks handled independently. Collaboration occurred via pigeon (internal messaging), email, or phone, with a weekly sync meeting and an annual global team meeting.

Typical Bug‑Fix Process

A bug‑fix cycle typically follows these steps:

Analyze the bug report and reproduce the issue.

Discuss possible solutions with senior engineers and create a new branch using bzr.

Implement the fix, add an appropriate MTR test case, and submit the code for review on ReviewBoard, often undergoing several rounds of rigorous review.

Run the changes on an automated test cluster that builds both debug and release binaries across multiple platforms.

After successful testing, merge the changes into the main trunk.

More complex feature development also requires creating a worklog, completing high‑level and low‑level design documents, and building prototypes before coding.

Major Contributions

During six years on the InnoDB team, the author made 461 commits, contributing to several key features, including:

GIS support: R‑tree index, geometry datatype handling, DML operations on spatial indexes, and enhanced check table for spatial indexes.

Transparent Data Encryption (TDE) for tables, redo logs, and undo tablespaces.

New Data Dictionary (DD) enhancements such as table encryption, compression, removal of legacy system tables, and import/export support.

Selected worklog entries:

WL#6968 – InnoDB GIS: R‑tree index support

WL#6455 – InnoDB: GEOMETRY datatype support

WL#8548 – InnoDB: Transparent data encryption

WL#9290 – InnoDB: TDE for redo log

WL#9531 – InnoDB_New_DD: Enable table encryption and transparent compression

Reflections and Departure

The author values the exposure to a mature open‑source development process and the opportunity to work with world‑class engineers. After leaving MySQL, he joined Tencent Cloud’s CDB (TXSQL) team, continuing to contribute to the MySQL ecosystem. He notes that the rapid growth of cloud providers and the closure of Oracle’s China R&D center created a turning point for many MySQL engineers.

He plans to publish further articles sharing technical insights about MySQL and its Tencent variant.