{"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\/de\/mysql-datenherkunft\/","title":{"rendered":"MySQL-Datenherkunft: Spaltenherkunft durch Views und ETL-SQL verfolgen"},"content":{"rendered":"

MySQL-Datenherkunft<\/strong> ist die spaltenweise Darstellung des Datenflusses durch Ihre MySQL-Sichten. EINF\u00dcGEN ... AUSW\u00c4HLEN<\/code> Jobs und ETL-Skripte: Welche Quellspalten speisen welche Zielspalten und welche Joins, Filter und Aggregationen werden verwendet? MySQL selbst kann Ihnen das nicht anzeigen. Informationsschema<\/code> beschreibt die Struktur, nicht den Datenfluss. Gudu SQLFlow<\/a> Die Datenherkunft wird automatisch erstellt, indem Ihr MySQL-SQL-Code mit einem speziellen MySQL-Dialektparser analysiert wird. Dadurch entsteht ein interaktives, bis auf einzelne Spalten herunterf\u00fchrbares Diagramm.<\/p>\n\n\n\n

\n\n

Sehen Sie es sich in Ihrer eigenen SQL-Datenbank an:<\/strong> F\u00fcgen Sie eine beliebige MySQL-Ansicht ein oder EINF\u00dcGEN ... AUSW\u00c4HLEN<\/code> in die kostenloser SQLFlow-Lineage-Visualisierer<\/a>W\u00e4hlen Sie den MySQL-Dialekt aus und erhalten Sie in Sekundenschnelle ein Spalten-Herkunftsdiagramm.<\/p>\n\n<\/div><\/div>\n\n\n\n

Warum information_schema keine MySQL-Datenherkunft liefern kann<\/h2>\n\n\n\n

MySQL Informationsschema<\/code> ist ein Strukturkatalog. Er wird Ihnen sagen, dass Tageseinnahmen<\/code> hat f\u00fcnf Spalten, die deren Datentypen angeben, und (via KEY_COLUMN_USAGE<\/code>) welche Fremdschl\u00fcssel wohin verweisen. Was es Ihnen niemals sagen wird, ist, dass t\u00e4gliche_Einnahmen Nettoeinnahmen<\/code> wird berechnet aus Bestellungen.Betrag<\/code> Minus Bestellungen.Rabatt<\/code>gefiltert nach Bestellungen.Status<\/code>und gruppiert nach Kundenregion<\/code>.<\/p>\n\n\n\n

Dieses Wissen \u00fcber den Datenfluss ist nur an einer Stelle gespeichert: im SQL-Text selbst. In einer typischen MySQL-Umgebung bedeutet das View-Definitionen (information_schema.VIEWS<\/code> speichert den Text, aber nichts interpretiert ihn), EINF\u00dcGEN ... AUSW\u00c4HLEN<\/code> Und BEI DUPLIKATSCHL\u00dcSSELAKTUALISIERUNG<\/code> Anweisungen, die Ihre ETL-Jobs ausf\u00fchren, generierte Spaltenausdr\u00fccke in Ihrem DDL und anwendungsseitige Abfragedateien. Um diese in Herkunftsinformationen umzuwandeln, muss etwas den SQL-Code analysieren und semantisch aufl\u00f6sen \u2013 erweitern. W\u00c4HLEN *<\/code>SQLFlow verfolgt Spalten \u00fcber Joins, Unterabfragen und View-Stacks hinweg.<\/p>\n\n\n\n

Ein praktisches Beispiel: eine Berichtstabelle, die mit INSERT-SELECT gespeist wird<\/h2>\n\n\n\n

Hier ist die Art von Anweisung, die jede Nacht in Tausenden von MySQL-basierten Reporting-Systemen ausgef\u00fchrt wird \u2013 ein Upsert, der Bestellungen in einer \u00dcbersichtstabelle zusammenfasst:<\/p>\n\n\n\n

INSERT INTO daily_revenue (report_date, region, order_count, gross_revenue, net_revenue) SELECT o.order_date, c.region, COUNT(*), SUM(o.amount), SUM(o.amount - o.discount) FROM orders o JOIN customers c ON c.id = o.customer_id WHERE o.status = 'completed' GROUP BY o.order_date, c.region ON DUPLICATE KEY UPDATE order_count = VALUES(order_count), gross_revenue = VALUES(gross_revenue), net_revenue = VALUES(net_revenue);<\/code><\/pre>\n\n\n\n
Wenn Sie dies mit SQLFlow durchf\u00fchren, werden pro Zielspalte sowohl die Spalten extrahiert, die direkt ihren Wert liefern, als auch die Spalten, die das Ergebnis formen, ohne dabei selbst im Ergebnis zu landen:<\/p>\n\n\n\n
\n
Zielspalte<\/th>Direkte Quellen<\/th>Indirekte (Auswirkungs-)Einfl\u00fcsse<\/th><\/tr><\/thead>
Datum des Tagesumsatzberichts<\/code><\/td>orders.order_date<\/code><\/td>Bestellungen.Status<\/code><\/td><\/tr>\n
daily_revenue.region<\/code><\/td>Kundenregion<\/code><\/td>Kunden-ID<\/code>, orders.customer_id<\/code>, Bestellungen.Status<\/code><\/td><\/tr>\n
Tagesumsatz.Bruttoumsatz<\/code><\/td>Bestellungen.Betrag<\/code> \u00fcber SUMME()<\/code><\/td>orders.order_date<\/code>, Kundenregion<\/code> (GROUP BY), Verbindungsschl\u00fcssel, Bestellungen.Status<\/code><\/td><\/tr>\n
t\u00e4gliche_Einnahmen Nettoeinnahmen<\/code><\/td>Bestellungen.Betrag<\/code>, Bestellungen.Rabatt<\/code> \u00fcber SUMME()<\/code><\/td>gleich wie oben<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n
Die Unterscheidung in der dritten Spalte ist wichtig. Bestellungen.Status<\/code> erscheint nie in Tageseinnahmen<\/code>Doch die Art und Weise, wie die Daten erhoben werden, \u00e4ndert jede einzelne Zahl im Bericht. SQLFlow modelliert dies. indirekte Abstammung<\/strong> (Spalten, die in verwendet werden WO<\/code>, VERBINDEN<\/code>, Und GRUPPE NACH<\/code>) als separater, umschaltbarer Beziehungstyp im Diagramm \u2013 die meisten Abstammungsanalyse-Tools machen diese Unterscheidung \u00fcberhaupt nicht, und genau das ist es, was Sie f\u00fcr eine ehrliche Wirkungsanalyse ben\u00f6tigen.<\/p>\n\n\n\n
Herkunft \u00fcber MySQL-Views \u2013 einschlie\u00dflich gestapelter Views<\/h2>\n\n\n\n
Bei Ansichten sto\u00dfen die Datenherkunftsanalyse-Tools auf Tabellenebene stillschweigend an ihre Grenzen. Ein BI-Dashboard zeigt Folgendes an: v_regional_kpis<\/code>, das ausw\u00e4hlt v_completed_orders<\/code>, das ausw\u00e4hlt Bestellungen<\/code> Und Kunden<\/code>Um die Frage \u201eWelche Daten speisen diese Dashboard-Spalte?\u201c zu beantworten, muss die Datenherkunfts-Engine Spaltenreferenzen durch jede Ebene des Ansichtsstapels aufl\u00f6sen und alle Referenzen erweitern. W\u00c4HLEN *<\/code> gegen die zugrunde liegenden Definitionen und f\u00fchren die Transformationen mit sich.<\/p>\n\n\n\n
SQLFlow l\u00f6st Spaltenreferenzen mithilfe von Views, CTEs, Unterabfragen und Sternexpansion im Rahmen seiner semantischen Analyse auf. Wenn Sie SQLFlow \u00fcber JDBC auf Ihr Schema verweisen, ruft es die DDL- und View-Definitionen automatisch ab, sodass der Herkunftsgraph die Views so widerspiegelt, wie sie tats\u00e4chlich in der Datenbank existieren, und nicht wie sie in einem veralteten Migrationsordner vorliegen.<\/p>\n\n\n\n
Generierte Spalten: Herkunft innerhalb einer einzelnen Tabelle<\/h2>\n\n\n\n
Von MySQL generierte Spalten betten den Datenfluss direkt in die DDL ein:<\/p>\n\n\n\n
CREATE TABLE order_items ( quantity INT, unit_price DECIMAL(10,2), line_total DECIMAL(12,2) AS (quantity * unit_price) STORED );<\/code><\/pre>\n\n\n\n
Zeilensumme<\/code> wird niemals durch eine INSERT-Anweisung geschrieben, daher verfehlt jeder Ansatz, der nur DML \u00fcberwacht, seine Herkunft vollst\u00e4ndig. Da SQLFlow den Ausdruck der generierten Spalte als SQL interpretiert, Zeilensumme<\/code> erh\u00e4lt korrekte Abstammungskanten von Menge<\/code> Und Einzelpreis<\/code>und alles, was nachfolgend steht Zeilensumme<\/code> Die Spuren lassen sich alle auf diese beiden physischen S\u00e4ulen zur\u00fcckf\u00fchren.<\/p>\n\n\n\n
Wie man die MySQL-Herkunft mit SQLFlow erstellt<\/h2>\n\n\n\n
  1. Sammeln Sie die SQL-Anweisungen.<\/strong> F\u00fcgen Sie Anweisungen ein oder laden Sie Dateien hoch in SQLFlow Cloud<\/a>Alternativ k\u00f6nnen Sie Ihre MySQL-Instanz \u00fcber JDBC verbinden, sodass SQLFlow die DDL- und Ansichtsdefinitionen direkt liest. dbt-Benutzer k\u00f6nnen das dbt-Manifest importieren.<\/li>\n
  2. Parsen mit dem MySQL-Dialekt.<\/strong> SQLFlow verwendet einen dialektspezifischen MySQL-Parser (einen von 39 Dialektparsern, keine generische ANSI-Grammatik), daher sind MySQL-spezifische Konstrukte wie BEI DUPLIKATSCHL\u00dcSSELAKTUALISIERUNG<\/code>In Backticks gesetzte Bezeichner und generierte Spalten werden korrekt analysiert und nicht \u00fcbersprungen.<\/li>\n
  3. Erkunden und exportieren.<\/strong> Verfolgen Sie beliebige Spalten in der interaktiven Grafik, schalten Sie die indirekte Datenherkunft ein und aus und exportieren Sie die Grafik als JSON, CSV oder PNG \u2013 oder rufen Sie sie programmatisch \u00fcber die REST-API ab. Seit Version 8.2.3 k\u00f6nnen Sie au\u00dferdem Fragen in Klartext stellen (\u201eWelche Berichte h\u00e4ngen von \u2026 ab?\u201c). Kundenregion<\/code>Jede Tabelle und Spalte, die die KI zitiert, wird vor der Anzeige anhand des analysierten Diagramms validiert.<\/li><\/ol>\n\n\n\n
    Der darunterliegende Motor ist Allgemeiner 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
    Wie sieht es mit Open-Source-MySQL-Lineage-Optionen aus?<\/h2>\n\n\n\n
    Open-Source-Parser wie sqllineage<\/code> Und sqlglot<\/code> MySQL-SELECT- und INSERT-Anweisungen lassen sich gut verarbeiten, und wenn Sie die Datenherkunft f\u00fcr einige wenige einfache Abfragen innerhalb einer Python-Pipeline ben\u00f6tigen, sind sie ein guter Ausgangspunkt. Katalogplattformen wie DataHub und OpenMetadata sind stark in der Organisation und Darstellung der Datenherkunft, sobald diese vorhanden ist. Die L\u00fccke zeigt sich jedoch bei der Erstellung pr\u00e4ziser Datenherkunft aus komplexen SQL-Abfragen in gro\u00dfem Umfang: Spaltenaufl\u00f6sung durch gestapelte Ansichten mithilfe von Live-Schema-Metadaten, Unterscheidung zwischen direkter und indirekter Datenherkunft, Erweiterung der Datenherkunft W\u00c4HLEN *<\/code> SQLFlow konzentriert sich auf dieses Extraktionsproblem und speist die Ergebnisse anschlie\u00dfend \u00fcber seine Exportadapter f\u00fcr DataHub, Microsoft Purview und OpenMetadata in die Kataloge ein.<\/p>\n\n\n\n
    Wenn MySQL nur ein Teil des Bildes ist<\/h2>\n\n\n\n
    MySQL ist selten die alleinige Basis. Oft dient es als OLTP-Quelle f\u00fcr ein Data Warehouse oder als eine von mehreren Engines, die von einer ETL-Schicht genutzt werden. SQLFlow analysiert 39 SQL-Dialekte mit derselben Spaltenanalyse, sodass die Datenherkunft, die in MySQL beginnt und in Snowflake, BigQuery oder einer anderen Anwendung endet, nachvollziehbar ist. PostgreSQL<\/a> Die Daten befinden sich in einem einzigen Graphen. Enterprise-Implementierungen scannen Datenbanken mit \u00fcber 100 Datenbanken und mehr als einer Million Spalten im Batch-Verfahren, mit inkrementellen Scans und einem persistenten Herkunftsarchiv. F\u00fcr Teams, die verhindern m\u00fcssen, dass SQL-Text ihr Netzwerk verl\u00e4sst, SQLFlow vor Ort<\/a> L\u00e4uft auf Docker oder Kubernetes, vollst\u00e4ndig abgeschottet von der Au\u00dfenwelt.<\/p>\n\n\n\n
    Um zu sehen, wie die Ausgabe bei einer Reihe realer Anweisungen aussieht \u2013 Multi-Join-Einf\u00fcgungen, View-Stacks, gespeicherte Prozeduren \u2013 durchsuchen Sie die Beispiele f\u00fcr Datenherkunft<\/a>.<\/p>\n\n\n\n
    H\u00e4ufig gestellte Fragen<\/h2>\n\n\n\n
    Ben\u00f6tigt die Erstellung der MySQL-Datenherkunft Zugriff auf meine Daten?<\/h3>\n\n\n
    Nein. SQLFlow f\u00fchrt eine statische Analyse von SQL-Code und optional von Schema-Metadaten wie Tabellen- und Sichtdefinitionen durch. Es liest niemals Tabellenzeilendaten. Bei der On-Premise-Edition bleibt sogar der SQL-Text innerhalb Ihres Netzwerks.<\/p>\n\n\n\n
    Kann SQLFlow die Herkunft einer INSERT \u2026 SELECT \u2026 ON DUPLICATE KEY UPDATE-Anweisung nachverfolgen?<\/h3>\n\n\n
    Ja. Der MySQL-Dialektparser analysiert die gesamte Anweisung: Jede Zielspalte wird mit den Quellspalten in der SELECT-Anweisung verkn\u00fcpft, einschlie\u00dflich Ausdr\u00fccken innerhalb von Aggregaten, und die Upsert-Klausel wird als Teil desselben Datenflusses behandelt.<\/p>\n\n\n\n
    Enth\u00e4lt information_schema Herkunftsinformationen?<\/h3>\n\n\n
    NEIN. Informationsschema<\/code> Es beschreibt die Struktur: Tabellen, Spalten, Typen, Schl\u00fcssel und den Rohtext der Ansichtsdefinitionen. Es interpretiert kein SQL und kann daher nicht angeben, welche Quellspalten eine bestimmte Zielspalte speisen. Die Datenherkunft erfordert das Parsen der Ansicht und des DML-SQL, was SQLFlow \u00fcbernimmt.<\/p>\n\n\n\n
    Wie verarbeitet SQLFlow SELECT * in MySQL-Views?<\/h3>\n\n\n
    SQLFlow erweitert W\u00c4HLEN *<\/code> gegen das tats\u00e4chliche Schema (\u00fcber JDBC abgerufen oder als DDL bereitgestellt), sodass jede Spalte, die durch den Stern flie\u00dft, ihre eigene Herkunftskante erh\u00e4lt anstatt eines vagen Tabellen-zu-Tabellen-Pfeils.<\/p>\n\n\n\n
    Gibt es eine kostenlose M\u00f6glichkeit, die Datenherkunft von MySQL auszuprobieren?<\/h3>\n\n\n
    Ja. SQLFlow Cloud bietet eine kostenlose Version: F\u00fcgen Sie MySQL-SQL-Code in den Browser ein und erhalten Sie sofort das Spaltendiagramm. Die Premium-Version kostet $49,99\/Monat; die On-Premise-Version $500\/Monat oder einmalig $4.800 pro ausgew\u00e4hltem Datenbanktyp \u2013 siehe Preisgestaltung<\/a>.<\/p>\n\n\n\n
    Kann ich die MySQL-Datenherkunft in meinen Datenkatalog exportieren?<\/h3>\n\n\n
    Ja. Exportieren Sie als JSON, CSV oder PNG, fragen Sie die REST-API ab oder verwenden Sie die integrierten Exportadapter f\u00fcr DataHub, Microsoft Purview und OpenMetadata in Unternehmensumgebungen.<\/p>\n\n\n\n
    \n\n
    Erstellen Sie jetzt eine Karte Ihres MySQL-Datenflusses.<\/h2>\n\n\n
    F\u00fcgen Sie eine Ansicht oder eine INSERT-SELECT-Anweisung in den kostenlosen Visualisierer ein oder sprechen Sie mit uns \u00fcber die Durchsuchung Ihrer gesamten MySQL-Umgebung.<\/p>\n\n\n
    \n
    Testen Sie SQLFlow kostenlos<\/a><\/div>\n<\/div>\n\n\n
    \n
    Fordern Sie eine Enterprise-Demo an<\/a><\/div>\n<\/div>\n\n<\/div><\/div>\n\n\n\n