For many years, MySQL executed SQL queries using a deeply nested, monolithic executor loop. Functions like JOIN::exec() and evaluate_join_record() were responsible for traversing tables, checking search conditions, handling joins, and aggregating results. While functional, this monolithic architecture was notoriously difficult to maintain, optimize, or extend.

In MySQL 8.0, the engineering team undertook a massive architectural refactoring: migrating the query execution engine to the Volcano Iterator Model (also known as the Pipeline or Iterator Model, pioneered by Goetz Graefe in 1994).

In this post, we will explore the architecture and implementation of MySQL’s Volcano Iterator Model, look at how the query execution tree is built, and trace a concrete SQL query down to the C++ source code level.

Continue reading

Grouping and aggregation are cornerstones of relational databases. In MySQL, executing a GROUP BY statement involves a sophisticated dance between the query optimizer and the execution engine. With the introduction of the Volcano Iterator Model in modern MySQL (8.0+), this process has become highly modular, structured as a tree of self-contained iterators.

In this post, we’ll take a deep dive into the source code level of MySQL’s GROUP BY execution. We’ll start with the general flow and then dissect each major optimization and execution strategy with concrete SQL examples.

Continue reading

This article introduces the internal architecture and implementation details of MySQL’s default storage engine, InnoDB, exploring its memory structures, on-disk storage layouts, physical row formats, and Multi-Version Concurrency Control (MVCC) visibility rules.

Continue reading

Author's picture

Kevin Wang


software developer

Asia