Databases 19 min read

Understanding MySQL Index Structures, Execution Plans, Transactions, and MVCC

This article provides a comprehensive overview of MySQL internals, covering index data structures such as B‑tree and B+‑tree, the differences between MyISAM and InnoDB indexes, SQL execution plan analysis, transaction isolation levels, lock mechanisms, MVCC implementation, and the InnoDB buffer‑pool caching process.

Top Architect
Top Architect
Top Architect
Understanding MySQL Index Structures, Execution Plans, Transactions, and MVCC

MySQL indexes are built on underlying data structures like B+‑tree and hash; B+‑tree stores only leaf nodes with data, while hash is rarely used for sorting. Different tree types (binary tree, red‑black tree, B‑tree, B+‑tree) have trade‑offs in height, disk I/O, and memory usage.

MyISAM uses non‑clustered indexes where the index stores pointers to data files, whereas InnoDB has both primary (clustered) indexes that store the row data and secondary (non‑clustered) indexes that store the primary key for lookup, requiring a “back‑table” query.

SQL execution plans can be examined with EXPLAIN , revealing columns such as id, table, type (system, const, eq_ref, ref, range, index, ALL), key, rows, and Extra (e.g., Using index, Using where, Using temporary, Using filesort) that indicate how the optimizer will access data.

The execution flow of a SQL statement includes: establishing a TCP connection, checking the query cache (LRU eviction), parsing the SQL with a C‑based parser, optimizing the query (cost calculation, possible FORCE_INDEX), invoking the storage engine (InnoDB or MyISAM), and finally using the chosen index to retrieve rows.

Transaction isolation levels (read‑uncommitted, read‑committed, repeatable‑read, serializable) address concurrency problems such as dirty reads, non‑repeatable reads, and phantom reads. InnoDB supports row‑level locks (shared S‑lock and exclusive X‑lock) and uses gap locks to prevent phantom reads under repeatable‑read.

MySQL implements MVCC using a ReadView and an undo‑log version chain. Each row modification creates an undo record linked by hidden trx_id and roll_pointer fields; ReadView determines which versions are visible to a transaction, enabling consistent reads without locking.

InnoDB’s buffer‑pool caches pages in memory, writes modifications to the undo log, updates the buffer pool, records changes in the redo log buffer, and on commit flushes redo logs and binlogs to ensure durability and crash recovery.

Note: The article also contains promotional material for ChatGPT services and a community, which is not part of the technical discussion.

MySQLIndexesTransaction IsolationMVCCbuffer poolExecution Plan
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.