MySQL and MariaDB execution plans in Mini DBA

Mini DBA MySQL and MariaDB execution plan controls help you inspect EXPLAIN evidence for selected sessions and queries. The plan experience can include a visual diagram, EXPLAIN FORMAT=TREE output, EXPLAIN FORMAT=JSON output, a tabular operator list, an HTML export, and AI-assisted plan review.

Where to open MySQL and MariaDB plans

The richest MySQL and MariaDB plan controls appear from MySQL And MariaDB Activity, where a selected session can show SQL detail and execution plan data if it was collected. Query workflows can also lead you back to Activity when the expensive statement is currently running.

Use MySQL And MariaDB Queries to identify expensive statements by duration, frequency, reads, writes, or available cost measures. Then use Activity and plan detail when the query is active or when plan evidence has been captured.

Plan availability depends on server version, permissions, SQL text, selected database, storage engine, and whether the query can be explained safely. Some statements, temporary objects, prepared statements, or permission boundaries may limit what Mini DBA can show.

Plan tabs and controls

The MySQL/MariaDB plan modal and activity detail can show several complementary views:

• Diagram: a visual representation of the plan tree using available JSON, tree, and operator data.
• Tree: raw EXPLAIN FORMAT=TREE text where available.
• JSON: raw EXPLAIN FORMAT=JSON where available.
• Operators: tabular EXPLAIN rows with select type, table, access type, possible keys, chosen key, estimated rows, filtered percent, and Extra information.
• Open HTML: opens the plan as a standalone HTML page for easier review or handover.
• AI Assistant: sends the plan tree, JSON, operator rows, and source context to the Mini DBA AI Assistant.

Use the diagram to understand the shape of the plan, then use Tree, JSON, and Operators to capture precise evidence. The same problem may be easier to see in different views. For example, JSON can expose nested plan structure, while the Operators table makes access type and selected keys easy to scan.

Using the interactive diagram

The embedded diagram and the standalone HTML view provide the same navigation and emphasis controls:

• Use the chevron on an operation to fold or reveal that branch. A folded operation reports how many descendant operations are hidden.
• Expand all and Collapse all change the whole tree at once.
• Estimated hot path folds unrelated branches and follows the highest available optimizer cost or row estimate through the plan. If the supplied plan already contains actual timing and loop data, the control is labelled Actual hot path and uses actual time multiplied by loops instead.
• Expand warnings reveals the branches that contain scans, filesorts, temporary-table work, or other operations classified as warnings by the renderer. Warning badges name the reason on the affected operation, while parent badges report how many warnings are present further down the branch.
• Heat map can use automatic selection, actual time multiplied by loops, estimated cost, or estimated rows. The contribution bar and background intensity are relative to the largest value in the current plan; they are visual comparison aids rather than percentages of total query time.
• Minimap shows a compact overview of larger plans and highlights the currently visible region. Click or drag in it to navigate, or focus it and use the arrow, Home, and End keys. Mini DBA bundles the MIT-licensed Pagemap 1.4.1 library locally; plan data is rendered in the browser and is not sent to a third-party service.
• Hover over a metric or contribution bar to see its value. The controls use standard buttons and form fields, so they can also be reached and operated by keyboard.

Mini DBA does not run EXPLAIN ANALYZE automatically to obtain actual timings because MySQL executes the statement while producing that plan. Actual hot-path and actual-time heat-map options appear only when actual timing data is already present; ordinary captured plans remain clearly labelled as estimated.

Drill into expensive or risky operators

MySQL and MariaDB plans do not expose the same estimated cost model as SQL Server, so focus on access patterns, rows, filters, and Extra values. In the Operators tab, look for rows where the access type indicates broad scanning or weak selectivity, especially when rows is large and filtered percent is low.

Investigate:

• ALL access on large tables when a selective predicate should use an index.
• index scans that read many index entries rather than seeking to a narrow range.
• Missing selected key even though possible keys exist.
• Large estimated rows on early tables in a join.
• Low filtered percentage that suggests many rows are read and discarded.
• Extra values such as Using temporary, Using filesort, Using join buffer, Using where, or Using index condition.
• Join order that starts with an unselective table.

Access type alone is not enough. A table scan on a tiny lookup table may be fine, while a range scan on a huge table can still be expensive. Compare the plan with runtime symptoms from MySQL And MariaDB Activity, MySQL And MariaDB I/O, and MySQL And MariaDB InnoDB.

Tuning decisions from MySQL and MariaDB plans

Common tuning actions include adding or changing indexes, rewriting predicates so indexes are usable, reducing result size, changing join order through query design, removing unnecessary sorts, and checking whether statistics or table distribution has changed. For write-heavy tables, every additional index has a cost. Validate new indexes against INSERT, UPDATE, DELETE, storage, and replication impact.

If the plan points to locks or transaction delay rather than access path, use MySQL And MariaDB InnoDB and MySQL And MariaDB Deadlocks. A query can look slow because it waits, not because the plan is the root cause.

Ask AI about a MySQL or MariaDB plan

The AI Assistant tab passes available plan tree, JSON, and operators. This makes it useful for translating dense EXPLAIN output into an investigation checklist.

Useful prompts include:

Which table access pattern is the biggest concern in this MySQL execution plan?

Explain the chosen keys, possible keys, rows, filtered percentage, and Extra values.

What should I validate before adding an index for this query?

Use AI recommendations as a guide for evidence gathering. Confirm the change in a lower environment or controlled production window and compare before-and-after metrics.

Related pages

• Execution Plan Analysis
• MySQL And MariaDB Activity
• MySQL And MariaDB Queries
• MySQL And MariaDB I/O
• MySQL And MariaDB InnoDB
• MySQL And MariaDB Performance Tuning