Deep Dive into MySQL 8.0 Server Architecture, Parser, and Optimizer

The article is based on the MySQL 8.0.25 source code and focuses on the server layer (optimizer and executor). It first presents the overall layered architecture of MySQL 8, highlighting the evolution of InnoDB, NDB clusters, and the HeatWave (RAPID) memory‑cluster.

The parser in MySQL 8.0 has been rewritten with Bison, producing a parser tree that is then contextualized into an abstract syntax tree (AST). The legacy SELECT_LEX_UNIT/SELECT_LEX structures have been renamed to Query_block and Query_expression, respectively.

Example of a complex nested query is shown, followed by the MySQL‑specific representation of the same query.

(SELECT * FROM ttt1)
UNION ALL (SELECT * FROM (SELECT * FROM ttt2) AS a, (SELECT * FROM ttt3 UNION ALL SELECT * FROM ttt4) AS b)

After parsing, the AST is built on the Query_block/Query_expression framework, with some levels collapsed or merged.

The prepare/rewrite phase performs a series of setup and fix steps (setup_tables, resolve_placeholder_tables, setup_natural_join_row_types, etc.), followed by many transformation passes such as remove_redundant_subquery_clause, resolve_subquery, flatten_subqueries, simplify_joins, prune_partitions, and others.

For illustration, the article examines the simple_joins function that simplifies nested joins within a Query_block.

Comparison with PostgreSQL is provided: the PostgreSQL pipeline consists of a Parser (producing a parse tree), an Analyzer (semantic analysis to a query tree), and a Rewriter (rule‑based transformations). Sample SQL and view creation statements are shown.

The Optimize and Planning stage describes how MySQL 8.0.22+ switched from the traditional JOIN/QEP_TAB representation to a hypergraph‑based optimizer that uses HyperNode / HyperEdge structures. Sample plan trees for both left‑deep (JOIN) and bushy (hypergraph) representations are shown.

| -> Inner hash join (no condition) (cost=1.40 rows=1)
    -> Table scan on R4 (cost=0.35 rows=1)
    -> Hash
        -> Inner hash join (no condition) (cost=1.05 rows=1)
            -> Table scan on R3 (cost=0.35 rows=1)
            -> Hash
                -> Inner hash join (no condition) (cost=0.70 rows=1)
                    -> Table scan on R2 (cost=0.35 rows=1)
                    -> Hash
                        -> Table scan on R1 (cost=0.35 rows=1)

The new optimizer is activated with set optimizer_switch="hypergraph_optimizer=on" and works through FindBestQueryPlan , which checks query support, builds a JoinHypergraph , enumerates partitions using the DPhyp algorithm, and selects the lowest‑cost plan via CostingReceiver . Subsequent phases handle GROUP BY, aggregation, sorting, and limit processing.

Finally, the chosen AccessPath is turned into an iterator; each AccessPath maps 1:1 to a RowIterator implementation (e.g., TableScanIterator , IndexScanIterator ).

The article concludes that the analysis of MySQL’s latest source code reveals substantial architectural refactoring across multiple stages, providing readers with a clearer understanding of modern MySQL internals.