{"id":6757,"date":"2026-07-12T02:07:05","date_gmt":"2026-07-12T10:07:05","guid":{"rendered":"https:\/\/www.gudusoft.com\/mysql-data-lineage\/"},"modified":"2026-07-12T02:07:05","modified_gmt":"2026-07-12T10:07:05","slug":"mysql-data-lineage","status":"publish","type":"page","link":"https:\/\/www.gudusoft.com\/pt\/mysql-data-lineage\/","title":{"rendered":"MySQL Data Lineage: Trace Column Lineage Through Views and ETL SQL"},"content":{"rendered":"

MySQL data lineage<\/strong> is the column-by-column map of how data flows through your MySQL views, INSERT ... SELECT<\/code> jobs, and ETL scripts: which source columns feed each target column, and through which joins, filters, and aggregations. MySQL itself cannot show you this \u2014 information_schema<\/code> describes structure, not dataflow. Gudu SQLFlow<\/a> builds the lineage automatically by parsing your MySQL SQL with a dedicated MySQL dialect parser, producing an interactive, drillable diagram down to individual columns.<\/p>\n\n\n\n

\n\n

See it on your own SQL:<\/strong> paste any MySQL view or INSERT ... SELECT<\/code> into the Visualizador de linhagem SQLFlow gratuito<\/a>, pick the MySQL dialect, and get a column-level lineage diagram in seconds.<\/p>\n\n<\/div><\/div>\n\n\n\n

Why information_schema can’t give you MySQL data lineage<\/h2>\n\n\n\n

MySQL’s information_schema<\/code> is a structural catalog. It will tell you that daily_revenue<\/code> has five columns, what their types are, and (via KEY_COLUMN_USAGE<\/code>) which foreign keys point where. What it will never tell you is that daily_revenue.net_revenue<\/code> is computed from orders.amount<\/code> minus orders.discount<\/code>, filtered on orders.status<\/code>, and grouped by customers.region<\/code>.<\/p>\n\n\n\n

That dataflow knowledge lives in one place only: the SQL text itself. In a typical MySQL estate that means view definitions (information_schema.VIEWS<\/code> stores the text, but nothing interprets it), the INSERT ... SELECT<\/code> e ON DUPLICATE KEY UPDATE<\/code> statements your ETL jobs run, generated-column expressions in your DDL, and application-side query files. To turn those into lineage, something has to actually parse and semantically resolve the SQL \u2014 expanding SELECIONE *<\/code>, tracing columns through joins, subqueries, and view stacks. That is what SQLFlow does.<\/p>\n\n\n\n

A worked example: a reporting table fed by INSERT-SELECT<\/h2>\n\n\n\n

Here is the kind of statement that runs nightly in thousands of MySQL-backed reporting setups \u2014 an upsert that aggregates orders into a summary table:<\/p>\n\n\n\n

INSERT INTO daily_revenue\n  (report_date, region, order_count, gross_revenue, net_revenue)\nSELECT o.order_date,\n       c.region,\n       COUNT(*),\n       SUM(o.amount),\n       SUM(o.amount - o.discount)\nFROM orders o\nJOIN customers c ON c.id = o.customer_id\nWHERE o.status = 'completed'\nGROUP BY o.order_date, c.region\nON DUPLICATE KEY UPDATE\n  order_count   = VALUES(order_count),\n  gross_revenue = VALUES(gross_revenue),\n  net_revenue   = VALUES(net_revenue);<\/code><\/pre>\n\n\n\n
Run this through SQLFlow and it extracts, per target column, both the columns that directly supply its value and the columns that shape the result without landing in it:<\/p>\n\n\n\n
\n
Target column<\/th>Direct sources<\/th>Indirect (impact) influences<\/th><\/tr><\/thead>
daily_revenue.report_date<\/code><\/td>orders.order_date<\/code><\/td>orders.status<\/code><\/td><\/tr>\n
daily_revenue.region<\/code><\/td>customers.region<\/code><\/td>customers.id<\/code>, orders.customer_id<\/code>, orders.status<\/code><\/td><\/tr>\n
daily_revenue.gross_revenue<\/code><\/td>orders.amount<\/code> via SOMA()<\/code><\/td>orders.order_date<\/code>, customers.region<\/code> (GROUP BY), join keys, orders.status<\/code><\/td><\/tr>\n
daily_revenue.net_revenue<\/code><\/td>orders.amount<\/code>, orders.discount<\/code> via SOMA()<\/code><\/td>same as above<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n
The distinction in the third column matters. orders.status<\/code> never appears in daily_revenue<\/code>, yet changing how it is populated changes every number in the report. SQLFlow models this linhagem indireta<\/strong> (columns used in ONDE<\/code>, JOIN<\/code>, e AGRUPAR POR<\/code>) as a separate, toggleable relationship type in the diagram \u2014 most lineage tools do not make the distinction at all, and it is exactly what you need for honest impact analysis.<\/p>\n\n\n\n
Lineage through MySQL views \u2014 including stacked views<\/h2>\n\n\n\n
Views are where table-level lineage tools quietly give up. A BI dashboard reads v_regional_kpis<\/code>, which selects from v_completed_orders<\/code>, which selects from orders<\/code> e customers<\/code>. To answer “what feeds this dashboard column?”, the lineage engine must resolve column references down through every layer of the view stack, expand any SELECIONE *<\/code> against the underlying definitions, and carry the transformations along.<\/p>\n\n\n\n
SQLFlow resolves column references through views, CTEs, subqueries, and star expansion as part of its semantic analysis. Point it at your schema over JDBC and it pulls the DDL and view definitions itself, so the lineage graph reflects the views as they actually exist in the database, not as they exist in a stale migration folder.<\/p>\n\n\n\n
Generated columns: lineage inside a single table<\/h2>\n\n\n\n
MySQL generated columns embed dataflow directly in the DDL:<\/p>\n\n\n\n
CREATE TABLE order_items (\n  quantity   INT,\n  unit_price DECIMAL(10,2),\n  line_total DECIMAL(12,2) AS (quantity * unit_price) STORED\n);<\/code><\/pre>\n\n\n\n
line_total<\/code> is never written by any INSERT, so any approach that only watches DML misses its provenance entirely. Because SQLFlow parses the generated-column expression as SQL, line_total<\/code> gets proper lineage edges from quantity<\/code> e unit_price<\/code>, and anything downstream that reads line_total<\/code> traces all the way back to those two physical columns.<\/p>\n\n\n\n
How to build MySQL lineage with SQLFlow<\/h2>\n\n\n\n
  1. Collect the SQL.<\/strong> Paste statements or upload files into Nuvem SQLFlow<\/a>, or connect your MySQL instance over JDBC so SQLFlow reads the DDL and view definitions directly. dbt users can import the dbt manifest.<\/li>\n
  2. Parse with the MySQL dialect.<\/strong> SQLFlow uses a dialect-specific MySQL parser (one of 39 dialect parsers, not a generic ANSI grammar), so MySQL-specific constructs like ON DUPLICATE KEY UPDATE<\/code>, backtick-quoted identifiers, and generated columns are analyzed correctly rather than skipped.<\/li>\n
  3. Explore and export.<\/strong> Trace any column upstream or downstream in the interactive diagram, toggle indirect lineage on and off, and export the graph as JSON, CSV, or PNG \u2014 or pull it programmatically via the REST API. Since v8.2.3 you can also ask questions in plain English (“which reports depend on customers.region<\/code>?”); every table and column the AI cites is validated against the analyzed graph before display.<\/li><\/ol>\n\n\n\n
    The engine underneath is General SQL Parser<\/a>, a commercial SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect SQL test fixtures. Lineage quality is a parsing problem before it is anything else, and that regression corpus is what keeps real-world MySQL \u2014 with all its dialect quirks \u2014 from silently falling out of the graph.<\/p>\n\n\n\n
    What about open-source MySQL lineage options?<\/h2>\n\n\n\n
    Open-source parsers like sqllineage<\/code> e sqlglot<\/code> handle individual MySQL SELECT and INSERT statements well, and if you need lineage for a handful of straightforward queries inside a Python pipeline, they are a reasonable place to start. Catalog platforms such as DataHub and OpenMetadata are strong at organizing and displaying lineage once it exists. The gap shows up in producing accurate lineage from hard SQL at scale: resolving columns through stacked views using live schema metadata, distinguishing direct from indirect lineage, expanding SELECIONE *<\/code> correctly, and doing it across thousands of scripts. SQLFlow focuses on that extraction problem \u2014 and then feeds the results into the catalogs via its export adapters for DataHub, Microsoft Purview, and OpenMetadata.<\/p>\n\n\n\n
    When MySQL is only part of the picture<\/h2>\n\n\n\n
    MySQL is rarely the whole estate. It is often the OLTP source that feeds a warehouse, or one of several engines an ETL layer crosses. SQLFlow parses 39 SQL dialects with the same column-level analysis, so lineage that starts in MySQL and ends in Snowflake, BigQuery, or PostgreSQL<\/a> lives in one graph. Enterprise deployments batch-scan estates of 100+ databases and over a million columns, with incremental scans and a persistent lineage repository. For teams that cannot let SQL text leave their network, SQLFlow no local<\/a> runs on Docker or Kubernetes fully air-gapped.<\/p>\n\n\n\n
    To see what the output looks like across a range of real statements \u2014 multi-join inserts, view stacks, stored procedures \u2014 browse the data lineage examples<\/a>.<\/p>\n\n\n\n
    Perguntas frequentes<\/h2>\n\n\n\n
    Does building MySQL lineage require access to my data?<\/h3>\n\n\n
    No. SQLFlow performs static analysis of SQL code and, optionally, schema metadata such as table and view definitions. It never reads table row data. With the On-Premise edition, even the SQL text stays inside your network.<\/p>\n\n\n\n
    Can SQLFlow trace lineage through INSERT … SELECT … ON DUPLICATE KEY UPDATE?<\/h3>\n\n\n
    Yes. The MySQL dialect parser analyzes the full statement: each target column is linked to the source columns in the SELECT, including expressions inside aggregates, and the upsert clause is handled as part of the same dataflow.<\/p>\n\n\n\n
    Does information_schema contain lineage information?<\/h3>\n\n\n
    No. information_schema<\/code> describes structure: tables, columns, types, keys, and the raw text of view definitions. It does not interpret any SQL, so it cannot tell you which source columns feed a given target column. Lineage requires parsing the view and DML SQL, which is what SQLFlow does.<\/p>\n\n\n\n
    How does SQLFlow handle SELECT * in MySQL views?<\/h3>\n\n\n
    SQLFlow expands SELECIONE *<\/code> against the actual schema (pulled over JDBC or supplied as DDL), so every column that flows through the star gets its own lineage edge instead of one vague table-to-table arrow.<\/p>\n\n\n\n
    Is there a free way to try MySQL data lineage?<\/h3>\n\n\n
    Yes. SQLFlow Cloud has a free tier: paste MySQL SQL in the browser and get the column-level diagram immediately. Premium is $49.99\/month; On-Premise is $500\/month or $4,800 one-time per selected database type \u2014 see pre\u00e7os<\/a>.<\/p>\n\n\n\n
    Can I export the MySQL lineage into my data catalog?<\/h3>\n\n\n
    Yes. Export as JSON, CSV, or PNG, query the REST API, or use the built-in export adapters for DataHub, Microsoft Purview, and OpenMetadata in enterprise deployments.<\/p>\n\n\n\n
    \n\n
    Map your MySQL dataflow now<\/h2>\n\n\n
    Paste a view or an INSERT-SELECT into the free visualizer, or talk to us about scanning your whole MySQL estate.<\/p>\n\n\n
    \n
    Experimente o SQLFlow gratuitamente<\/a><\/div>\n<\/div>\n\n\n
    \n
    Solicite uma demonstra\u00e7\u00e3o empresarial<\/a><\/div>\n<\/div>\n\n<\/div><\/div>\n\n\n\n