server

MariaDB implements a bison-based SQL parser (sql_yacc.yy) coupled with a hand-coded lexer (sql_lex.h) that tokenizes and parses SQL statements into an abstract syntax tree (AST). The parser supports MySQL compatibility mode alongside MariaDB-specific extensions (Oracle PL/SQL compatibility, JSON operators, window functions). The lexer maintains state across multi-byte character sequences and handles dialect-specific keywords dynamically via the lex_keywords registry, enabling runtime switching between strict MySQL and extended MariaDB syntax without recompilation.

MariaDB allocates a dedicated thread (THD — Thread Handler Descriptor) per client connection, encapsulating all per-connection state including the current query, transaction context, temporary tables, user variables, and execution statistics. The THD object serves as the central context passed through the entire SQL processing pipeline (parser → optimizer → executor → storage engine). Thread management uses a thread pool (configurable via thread_stack and thread_cache_size) with per-thread memory arenas to minimize allocation contention. Connection-level isolation is enforced through THD-scoped locks and transaction isolation levels (READ UNCOMMITTED through SERIALIZABLE).

MariaDB supports prepared statements (sql/sql_prepare.cc) that separate SQL parsing and optimization from execution. A prepared statement is parsed once and compiled into an execution plan, then executed multiple times with different parameter values. Parameters are bound via placeholders (?) in the SQL text, preventing SQL injection attacks. The prepared statement cache (sql_prepare_cache) stores compiled plans in memory, enabling fast re-execution without re-parsing. Prepared statements support both text protocol (PREPARE/EXECUTE statements) and binary protocol (COM_STMT_PREPARE, COM_STMT_EXECUTE). The optimizer generates a generic plan that works for all parameter values, or a specialized plan if parameter values significantly affect the plan (e.g., different indexes for different value ranges).

MariaDB supports stored procedures and triggers (sql/sp.cc, sql/sp_head.cc) that enable procedural SQL execution within the database. Stored procedures are compiled into an intermediate representation (Item tree) that is executed by a virtual machine (sp_instr_* classes). Procedures support control flow (IF, WHILE, LOOP, CASE), variables, cursors, and exception handling (DECLARE ... HANDLER). Triggers are automatically executed in response to table modifications (INSERT, UPDATE, DELETE) and can enforce business logic or maintain denormalized data. Both procedures and triggers are stored in the mysql.proc and mysql.trigger tables and are recompiled on first execution. The procedural engine is single-threaded (executes within the query thread) and does not support parallel execution.

MariaDB supports a native JSON data type (sql/json_*.cc) that stores JSON documents in a binary format for efficient storage and querying. JSON values are accessed via path expressions (e.g., json_col->'$.key.subkey') that navigate the JSON structure. The JSON type supports a rich set of functions for querying (JSON_EXTRACT, JSON_CONTAINS), manipulation (JSON_SET, JSON_REPLACE, JSON_REMOVE), and aggregation (JSON_ARRAYAGG, JSON_OBJECTAGG). JSON paths can be indexed via generated columns, enabling efficient queries on JSON fields. The JSON implementation uses a binary encoding that preserves the original JSON structure while enabling fast access to nested values without full parsing.

MariaDB supports SQL window functions (sql/window.cc) that perform calculations across a set of rows (window) related to the current row. Window functions include ranking (ROW_NUMBER, RANK, DENSE_RANK), aggregation (SUM, AVG, COUNT over windows), and offset functions (LAG, LEAD). Windows are defined via OVER clauses that specify partitioning (PARTITION BY) and ordering (ORDER BY). Frame specifications (ROWS BETWEEN ... AND ...) define the range of rows included in the window. Window functions are evaluated after GROUP BY but before ORDER BY, enabling complex analytical queries. The execution engine uses a streaming approach where rows are processed in order and window calculations are updated incrementally.

MariaDB supports Common Table Expressions (CTEs) via the WITH clause, enabling named subqueries that can be referenced multiple times in a query. CTEs are useful for breaking complex queries into readable steps and avoiding code duplication. Recursive CTEs (WITH RECURSIVE) enable iterative computation — a base case (anchor member) is computed first, then the recursive member is applied repeatedly until no new rows are produced. Recursive CTEs are commonly used for hierarchical queries (organizational charts, category trees) and graph traversal. The execution engine uses a temporary table to store intermediate results from each iteration, with cycle detection to prevent infinite loops.

MariaDB's query optimizer (sql/opt_*.cc) implements a cost-based approach using table statistics (cardinality, index selectivity) to evaluate multiple join orderings and access paths. The optimizer performs range analysis (sql/opt_range.cc) to determine which index ranges satisfy WHERE clause predicates, then estimates I/O cost using a simplified model (random_page_read_cost, seq_read_cost system variables). Join ordering uses a greedy algorithm with branch-and-bound pruning to avoid exponential explosion on large joins. The optimizer also applies subquery flattening, derived table merging, and condition pushdown to simplify query plans before execution.

InnoDB is MariaDB's default transactional storage engine, implementing ACID guarantees through a multi-version concurrency control (MVCC) system, redo logging, and row-level locking. The buffer pool (configurable via innodb_buffer_pool_size) caches pages in memory using an LRU eviction policy with a young/old generation split to reduce scan pollution. Transactions are isolated via snapshot isolation (REPEATABLE READ) or locking (SERIALIZABLE), with deadlock detection via a wait-for graph. The redo log (innodb_log_file_size) enables crash recovery by replaying committed transactions. Data is organized in B+ tree indexes with clustered primary keys, enabling efficient range scans and point lookups.

MariaDB implements full-text search (FTS) via inverted indexes that map keywords to document IDs and positions. FTS indexes are created on CHAR, VARCHAR, or TEXT columns and support boolean search (AND, OR, NOT operators), phrase search (quoted strings), and relevance ranking via BM25-style scoring. The FTS index is maintained incrementally during INSERT/UPDATE/DELETE operations, with a separate auxiliary table (FTS_*_INDEX_*) storing the inverted index. Query execution uses a two-phase approach: first, the FTS index identifies candidate documents; second, the main table is scanned to retrieve full rows and compute relevance scores. FTS supports both InnoDB and MyISAM storage engines with slightly different implementation details.

MariaDB Galera Cluster (via WSREP — Write Set Replication protocol) enables multi-master replication where all nodes can accept writes and maintain strong consistency. Write operations are executed locally first, then the write set (modified rows and their before/after images) is broadcast to all cluster nodes for certification (conflict detection) and application. Certification uses a deterministic algorithm to detect write conflicts (two transactions modifying the same row) and abort conflicting transactions on non-originating nodes. Replication is synchronous — a transaction commits only after all nodes acknowledge the write set, ensuring zero data loss. Cluster membership is managed via a gossip protocol with automatic node discovery and failure detection.

MariaDB abstracts storage engine implementations behind a handler interface (sql/handler.h) that defines virtual methods for table operations (open, close, read, write, delete, scan). Storage engines implement the handler interface to provide their own data organization, indexing, and transaction semantics. The handler interface supports multiple storage engines coexisting in the same server instance, with per-table engine selection via the ENGINE clause in CREATE TABLE. The SQL layer communicates with storage engines through the handler API, passing query plans (JOIN_TAB) and receiving row data. Storage engines can register custom system variables, status variables, and information schema tables via the plugin system.

MariaDB's binary log (sql/log.cc, sql/log_event.cc) records all data-modifying operations (INSERT, UPDATE, DELETE, DDL) in a sequential log file, enabling replication to slave nodes and point-in-time recovery (PITR). The binary log uses a row-based format (RBR) or statement-based format (SBF) to record changes. RBR logs the actual row modifications (before/after images), ensuring deterministic replication even with non-deterministic statements (e.g., RAND(), NOW()). SBF logs the original SQL statement, reducing log size but requiring deterministic execution. The binary log is organized into numbered files (mysql-bin.000001, mysql-bin.000002, etc.) with a corresponding index file. Replication slaves read the binary log and apply events to maintain a copy of the master's data.

MariaDB's partitioning system (sql/sql_partition_admin.h, sql/partition_info.cc) divides large tables into smaller partitions based on partition keys (columns or expressions). Supported partitioning strategies include RANGE (partition by value ranges), HASH (partition by hash function), LIST (partition by discrete values), and COLUMNS (partition by multiple columns). The optimizer performs partition pruning — analyzing WHERE clauses to determine which partitions contain matching rows — and only scans relevant partitions, reducing I/O. Partitions can be stored in different tablespaces or on different disks, enabling per-partition tuning. Partition maintenance operations (ADD PARTITION, DROP PARTITION, REORGANIZE PARTITION) are performed online without locking the entire table.

MariaDB implements authentication via user accounts (user@host) with password verification and access control via a privilege system (sql/sql_acl.cc). Privileges are granted at multiple levels: global (all databases), database, table, column, and routine (stored procedures). The privilege system uses a role-based approach where roles are collections of privileges that can be assigned to users. Authentication supports multiple methods: native password hashing (mysql_native_password), SHA-256 hashing (sha256_password), and pluggable authentication (via auth plugins). Access control is enforced at query execution time — the SQL layer checks privileges before executing statements. Privilege information is cached in memory (acl_cache) for performance, with cache invalidation on privilege changes.