MySQL Data Analysis with AI: From Plain English to Verified Query in Five Stages

A worked walkthrough of MySQL data analysis with AI: the five-stage agent loop applied to a real e-commerce schema, with the SQL the agent actually writes and the checks that catch its mistakes.

Direct answer: what MySQL data analysis with AI does

What "analysis with AI" actually means for MySQL

The phrase covers three very different things in vendor marketing. The first is autocomplete inside MySQL Workbench — a model finishes your SELECT for you. The second is a chat box that calls one text-to-SQL request per turn. Neither owns the workflow.

The third — and the one this page is about — is an agent loop. The agent decides which MySQL tables to read, when to ask its knowledge base for a definition, when its own output needs another check, and what to show you for approval. Anthropic frames this as a system that directs its own processes and tool usage rather than following a fixed script.

That distinction is the entire reason this category exists. A text-to-SQL feature gives you SQL. A MySQL AI agent gives you an answer, the SQL it ran to get there, the checks it ran on the result, and the business definitions it relied on. For the buyer-side comparison, see our MySQL data analysis tools guide.

Worked example: a real MySQL e-commerce question

The schema below is the e-commerce shape we have seen in dozens of MySQL deployments. Five tables — orders, customers, order_items, products, channels — with the foreign keys you would expect.

The question your team types into the agent:

"Why did East China repeat purchases drop 18% last quarter?"

No SQL. No table names. The agent does the rest in five stages.

The five-stage MySQL AI workflow

Stage 1 — context retrieval, with pseudo-output

The agent does not look at MySQL first. It queries the bound knowledge base. The retrieved facts shape every downstream stage.

retrieve("repeat purchase definition")
→ "A repeat purchase is a customer's second status='F' order
   placed within 90 days of their first."
retrieve("orders.status enum")
→ "P=pending, F=finalized, R=refunded, X=cancelled"
retrieve("East China region codes")
→ "CN-31, CN-32, CN-33, CN-34"

Stage 2 — plan, in human words

The agent shows you the plan in plain language, not SQL, and waits.

PLAN
1. Filter orders to status='F' and region_code IN (CN-31..CN-34)
2. Define "repeat" = 2nd F order within 90 days of first F order per customer
3. Compare Q1 vs Q2 repeat counts and repeat rate
4. Break down by channels.type to find which channel moved
5. Output: table + bar chart, row count + Q-over-Q delta

You spot one thing: you want the breakdown by channels.name, not channels.type. You edit. The agent re-plans only that step.

Stage 3 — the SQL the agent actually writes

SELECT c.region_code, ch.name AS channel_name,
       COUNT(DISTINCT o.customer_id) AS repeat_customers
FROM orders o
JOIN customers c ON c.customer_id = o.customer_id
JOIN channels ch ON ch.channel_id = o.channel_id
JOIN (
  SELECT customer_id, MIN(order_ts) AS first_ts
  FROM orders WHERE status = 'F' GROUP BY customer_id
) f ON f.customer_id = o.customer_id
WHERE o.status = 'F'
  AND c.region_code IN ('CN-31','CN-32','CN-33','CN-34')
  AND o.order_ts BETWEEN f.first_ts + INTERVAL 1 DAY
                      AND f.first_ts + INTERVAL 90 DAY
  AND o.order_ts >= '2026-01-01'
GROUP BY c.region_code, ch.name;

Stage 4 — verification before you see the number

The agent self-checks the result before delivery. A failed check triggers a re-plan, not a confident wrong answer.

VERIFY
- rows returned: 14,238
- null rate on channel_name: 0.4% (within tolerance)
- second-path check: repeat_rate via customer cohort = 11.7% (matches)
- Q-over-Q delta: -18.2%  ✓ consistent with the question

Stage 5 — what gets delivered

The agent returns the answer with the audit trail. You see the chart, the SQL, the definitions cited, and the row counts. Anyone reviewing this number can re-run the same SQL by hand and reproduce it.

Bound knowledge base for MySQL — the part that changes everything

The single biggest determinant of MySQL AI quality is not the model. It is whether the agent's MySQL connection is paired with a curated knowledge base. The agent retrieves from this KB as a tool call before it runs SQL.

Consider a concrete MySQL telemetry case. Suppose events.metric_key contains values like download:tool:windows:x64:agent_excel. Against an unbound MySQL connection, the agent counts rows by metric_key and reports raw values — accurate but uninterpretable. Against a connection bound to a KB that defines agent_excel = Office workflow automation demand, the agent computes the same counts and explains the cluster as Office workflow automation demand, separating computed facts from interpretation.

The database tells the agent what happened. The bound knowledge base tells the agent what it means.

Plan mode in 60 seconds

Plan mode is the explicit user-review checkpoint between stage 2 and stage 3. It is the smallest possible safety mechanism that meaningfully changes what your security team will sign off on.

What you see: the sources the agent will read, the joins it will write, the time window, the output shape. What you do: approve, edit a step, or reject. What the agent does: re-plans only the edited steps; never executes against MySQL until you approve. This is a direct application of the ReAct pattern — interleaving reasoning steps with actions reduces error against single-shot generation.

Plan mode also documents your changes. The final evidence trail shows the original plan and the edits, so a reviewer can see what the agent proposed and what the human caught.

Joining MySQL with other sources in one query

Pure-MySQL questions are the easy case. The questions that actually break tools are the ones that span MySQL plus a CSV plus a Supabase user table.

Extend the worked example: "Match the East China repeat-purchase customers to their CRM phone numbers from customers.csv, then check whether their auth.users records in our Supabase project show the same signup region." The agent retrieves schema from MySQL, ingests the CSV, queries Supabase, joins on phone_hash, and returns the cross-source view in one request — without ETL.

This is a documented InfiniSynapse capability across MySQL, PostgreSQL, Snowflake, Supabase, and S3, plus uploaded CSV and Excel files. The relevant intermediate representation, InfiniSQL, connects to a multi-source execution layer rather than forcing every source into one warehouse first. For the Supabase side specifically, see our Supabase data analysis with AI guide.

MySQL-specific gotchas the agent handles

Collation and charset edge cases

MySQL's default collation has changed across versions, and case-insensitive collations like utf8mb4_0900_ai_ci can make 'East' and 'east' match in a JOIN. The agent reads information_schema.columns during stage 1 and flags collation mismatches in the plan instead of producing a quietly wrong join.

NULL handling

MySQL treats NULL as not-equal-to-anything-including-itself. An agent that writes WHERE channel_id = NULL instead of IS NULL will silently return zero rows. The verification step in stage 4 catches this by flagging unexpected zero-row results before delivery.

ENUM interpretation

An ENUM like orders.status with values 'P','F','R','X' is meaningless without a dictionary. The bound KB attaches F=finalized so the agent does not have to guess. Without the KB, the agent will frequently guess "F=failed" — exactly inverting your revenue number.

JSON columns

MySQL JSON columns store nested data the agent must query with JSON_EXTRACT or the ->> operator. The agent reads the JSON shape during schema retrieval and produces the right extraction syntax instead of treating the column as opaque text.

Timezone columns

MySQL stores DATETIME without a timezone and TIMESTAMP with implicit server-zone conversion. Cross-region analysis goes wrong fast when one table uses each. The agent flags mixed temporal types in the plan and asks which zone to normalize to.

Honest limits

These limits are not pessimism. They are the contract your team needs before you put an agent in front of MySQL. Governance frameworks like the NIST AI Risk Management Framework exist precisely so your security team can sign off on the boundary.

FAQ

Sources and references

1. [Vendor] MySQL official documentation. dev.mysql.com/doc.
2. [Independent] BIRD text-to-SQL benchmark — human accuracy 92.96%. bird-bench.github.io.
3. [Independent] Yu et al. Spider text-to-SQL benchmark. yale-lily.github.io/spider.
4. [Independent] Yao et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv 2210.03629.
5. [Vendor] Anthropic (2024). Building Effective Agents. anthropic.com/research/building-effective-agents.
6. [Independent] Wikipedia. Retrieval-augmented generation. en.wikipedia.org/wiki/Retrieval-augmented_generation.
7. [Independent] NIST AI Risk Management Framework 1.0 (2023). nist.gov/itl/ai-risk-management-framework.
8. [Independent] European Commission. EU AI Act entered into force 2024-08-01. EU AI Act.

Related guides