Funktioniert MySQL in China? Data Residency, Lokalisierung & PIPL-Grenztransfer
MySQL ist kostenlose, quelloffene Software, die Sie überall selbst hosten — einschließlich auf Festlandchina-Boden — die Engine ist also residency-neutral und nie gesperrt. Die eigentliche Frage ist, wo Sie es betreiben: ein offshore gelegenes oder Nicht-China-Region-verwaltetes MySQL lässt die Datensätze Ihrer China-Nutzer offshore, eine PIPL-Grenz- und Datenlokalisierungs-Exponierung. Ein Compliance-zuerst-Blick auf MySQL und China Data Residency.
Funktioniert MySQL in China?
MySQL ist in China nicht gesperrt und läuft problemlos — die eigentliche Frage ist also eine Data-Residency-Frage: wo die personenbezogenen Daten, die es hält, zur Ruhe kommen dürfen.
MySQL ist kostenlose, quelloffene Software (GPL-lizenziert, im Besitz von Oracle), die Sie herunterladen und selbst betreiben, was die Engine residency-neutral macht — Sie können es auf Festlandchina-Boden selbst hosten, und das ist der rechtmäßige Hebel. Die Exponierung ist die Bereitstellung: ein verwaltetes MySQL in einer Global-Cloud-Region (Amazon RDS und Aurora, Azure Database for MySQL, Google Cloud SQL) oder einer beliebigen Nicht-China-Region lässt die personenbezogenen Daten Ihrer chinesischen Nutzer offshore — ein grenzüberschreitender Transfer, den PIPL regelt, bei jedem Lesen und Schreiben. Für einen Betreiber kritischer Informationsinfrastruktur oder Handler mit hohem Volumen müssen diese Daten im Festland bleiben (Cybersicherheitsgesetz Artikel 39, vormals Artikel 37; PIPL Artikel 40), was keine offshore gelegene Datenbank erfüllen kann. Inländisches verwaltetes MySQL existiert, aber nur auf separaten souveränen Clouds (AWS China über Sinnet und NWCD, Azure China über 21Vianet, Alibaba Cloud ApsaraDB) — eine inländische Region ist keine automatische Compliance.
Dies ist eine Risikokarte, kein Urteil — Ihre Pflichten hängen von Ihrer Rechtsperson, Ihren Datenmengen und wessen Daten Sie halten ab. Unser China-Team kann Ihre Exponierung kartieren →
Compliance-Momentaufnahme
- ! MySQL läuft problemlos in China — wo Sie es betreiben, ist die Compliance-Frage
- ✕ Offshore oder Nicht-China-Region-MySQL hält Ihre China-Daten außerhalb des Festlands
- ! Die Datensätze von China-Nutzern offshore = ein PIPL-Grenztransfer (Art. 38–40)
- ! CIIO- / Handler mit hohem Volumen schulden inländische Speicherung, die keine offshore gelegene DB erfüllen kann
- ! Souveränes inländisches verwaltetes MySQL existiert (AWS/Azure/Alibaba China) — separate Clouds
- ✓ MySQL im Inland betreiben + über ICP-eingereichte Infrastruktur ausliefern — keine Migration
Was die offizielle MySQL-Dokumentation über China sagt
| Fakt | Primärquelle |
|---|---|
| MySQL ist kostenlose, quelloffene Software, die Sie selbst betreiben — die Engine ist also residency-neutral, nicht gesperrt. In seinen eigenen Worten „MySQL Community Edition is the freely downloadable version of the world's most popular open source database", „available under the GPL license" und läuft auf „over 20 platforms and operating systems including Linux, Unix, Mac and Windows". Weil Sie den Server herunterladen und installieren, wo immer Sie wählen, können Sie MySQL auf Festlandchina-Infrastruktur selbst hosten — der rechtmäßige Hebel, um China-Daten auf chinesischem Boden zu halten. | MySQL Community Edition — mysql.com, abgerufen 2026-10-10 |
Verwaltetes MySQL in den globalen Clouds hat keine Festlandchina-Region; die inländischen Optionen sind separate souveräne Clouds. Amazon RDS und Aurora MySQL-Compatible, Azure Database for MySQL und Google Cloud SQL for MySQL deployen nur auf die globalen Regionen ihrer Anbieter — Google gibt an „Cloud SQL is available in all Google Cloud regions", deren nächste Asien-Einträge Taiwan (asia-east1) und Hongkong (asia-east2) sind, keine im Festland China. Im Inland läuft verwaltetes MySQL nur auf separaten souveränen Clouds mit eigenen Konten: AWS Chinas aws-cn-Partition, betrieben von Beijing Sinnet und Ningxia Western Cloud Data (NWCD), Azure China betrieben von 21Vianet und Alibaba Clouds ApsaraDB RDS for MySQL — jede mit eigener ICP und eigenen Compliance-Pflichten. | Google Cloud SQL for MySQL — instance locations (cloud.google.com), abgerufen 2026-10-10 |
| Für einen CIIO oder Handler mit hohem Volumen müssen in China gesammelte Daten im Festland gespeichert werden — eine Pflicht, die keine offshore gelegene Datenbank erfüllt. In Festlandchina gesammelte oder erzeugte personenbezogene Daten müssen innerhalb davon gespeichert werden (Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37) — die Cybersicherheitsgesetz-Novelle von 2025, in Kraft seit 1. Januar 2026, nummerierte den Datenlokalisierungs-Artikel von 37 auf 39 um, Substanz unverändert; und PIPL Artikel 40). Eine MySQL-Instanz offshore, oder in einer Nicht-China-verwalteten Region, hat keine Festland-Kopie, um diese inländische Speicherpflicht zu erfüllen; im Inland selbst zu hosten, oder ein lizenziertes souveränes verwaltetes MySQL, tut es. | Cybersecurity Law Article 39 (formerly Article 37); PIPL Article 40 |
| Die personenbezogenen Daten von China-Nutzern in einem offshore gelegenen MySQL sind ein grenzüberschreitender Transfer nach PIPL. Wo von Menschen im Festland China gesammelte personenbezogene Daten außerhalb davon gespeichert oder verarbeitet werden, macht PIPL den Handler — Sie, nicht Oracle oder die Cloud — dafür verantwortlich, Mitteilung zu geben, gesonderte Einwilligung einzuholen und einen Transfermechanismus zu erfüllen: eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung (Artikel 38–43). Jedes Lesen und Schreiben aus China zu einer offshore gelegenen Datenbank wiederholt diesen Transfer. | PIPL Articles 38–43 — cac.gov.cn, abgerufen 2026-10-10 |
Quellen vom 21YunBox Compliance-Team am 10. Oktober 2026 geprüft.
Für ein Festlandchina-Publikum ist die entscheidende Frage zu MySQL nicht, ob es sich installiert, verbindet oder eine Abfrage zurückgibt — das tut es, überall — sondern wo die Daten, die es hält, zur Ruhe kommen dürfen. MySQL ist das System of Record hinter unzähligen Anwendungen: Kundendatensätze, Benutzerkonten, Logins, Bestellungen und Transaktionen und die personenbezogenen Daten, die in all dem eingewickelt sind. MySQL ist auf dieser Liste ungewöhnlich, weil es kostenlose, quelloffene Software ist, die Sie herunterladen und selbst betreiben: die Engine ist residency-neutral, nie gesperrt, und läuft vollkommen gut auf Festlandchina-Boden. Das ist genau der rechtmäßige Hebel. Die Compliance-Exponierung ist nicht die Engine — es ist, wo und wie Sie sie deployen. Betreiben Sie sie auf einem offshore gelegenen verwalteten Dienst oder in einer Cloud-Region außerhalb Chinas, und die personenbezogenen Daten Ihrer chinesischen Nutzer leben auf der falschen Seite der Grenze. Betreiben Sie sie im Inland, und das tun sie nicht.
asia-east1 (Taiwan) und asia-east2 (Hongkong) sind, mit keiner im Festland China. Die Engine selbst installiert sich überall, einschließlich auf Festland-Boden; es ist die verwaltete Bereitstellung, die eine nur-offshore Regionsliste erbt. Quelle: cloud.google.com/sql/docs/mysql/locationsMySQL in China auf einen Blick
| Was darüber entscheidet | In MySQLs eigenen Worten — und Chinas Recht |
|---|---|
| Wo die Daten physisch ruhen | MySQL speichert Daten, wo immer Sie den Server installieren. Hosten Sie es selbst, und die Daten leben auf dieser Maschine; nutzen Sie ein verwaltetes MySQL, und sie leben in der Region, die dieser Dienst bietet — und Google Cloud SQL for MySQL ist zum Beispiel „available in all Google Cloud regions", von denen keine im Festland China ist. |
| Was MySQL hält | Das System of Record: Kundendatensätze, Benutzerkonten, Logins, Bestellungen und Transaktionen. Fast all das sind personenbezogene Daten, wo die Datenbank sitzt, ist also, wo diese personenbezogenen Daten sitzen. |
| Die Datensätze Ihrer China-Nutzer | In einer offshore gelegenen Region oder einem Nicht-China-verwalteten Dienst gehalten, ruhen die personenbezogenen Daten Ihrer chinesischen Nutzer außerhalb des Festlands — ein grenzüberschreitender Transfer, den PIPL regelt (Artikel 38–40), bei jedem Lesen und Schreiben über die Grenze getragen. |
| Die inländische Speicherpflicht | Für einen Betreiber kritischer Informationsinfrastruktur oder einen Handler mit hohem Volumen müssen in China gesammelte personenbezogene Daten im Festland bleiben (PIPL Artikel 40; Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37)). Eine offshore gelegene Datenbank kann diese Pflicht nicht erfüllen. |
| Ist es erreichbar? | Erreichbarkeit ist nicht die Achse — MySQL ist quelloffene Software, keine gesperrte Website. Der rechtmäßige Pfad ist, es im Inland zu betreiben: selbst-gehostet auf Festland-Infrastruktur oder auf einer lizenzierten Sovereign-Cloud-Option, mit der China-gerichteten Oberfläche auf einem ICP-eingereichten Fundament. |
Wo die Daten tatsächlich ruhen
MySQL selbst hat keine Heimat-Region — es läuft auf der Maschine, auf die Sie es setzen, was genau der Grund ist, warum die Engine residency-neutral ist. Die Residency-Frage landet ganz auf Ihrer Bereitstellung. Laden Sie MySQL herunter und betreiben Sie es auf einem Server innerhalb des Festlands China, und die Daten ruhen auf chinesischem Boden. Richten Sie Ihre Anwendung auf ein verwaltetes MySQL in einer globalen Cloud, und die Daten ruhen, wo immer dieser Dienst eine Region bietet.
Da ist, wo die verwaltete Landschaft wichtig ist. In den globalen Clouds — Amazon RDS und Aurora MySQL-Compatible, Azure Database for MySQL, Google Cloud SQL for MySQL — wählen Sie aus den Regionen des Anbieters, und keine in der globalen Partition sitzt innerhalb des Festlands China. Google ist explizit, dass „Cloud SQL is available in all Google Cloud regions”, und seine nächsten Asien-Regionen sind Taiwan (asia-east1) und Hongkong (asia-east2) — nah, erreichbar und immer noch außerhalb des Festlands für Residency-Zwecke; Google Cloud hat überhaupt keine Festland-Region. Ein verwaltetes MySQL dort hält Ihre China-Daten offshore.
Im Inland existiert verwaltetes MySQL — aber nur auf separaten, souveränen Clouds, die über ihre eigenen Konten erreicht werden: AWS China ist eine eigene aws-cn-Partition, betrieben von Beijing Sinnet (cn-north-1) und Ningxia Western Cloud Data, oder NWCD (cn-northwest-1); Azure China wird von 21Vianet betrieben; und Alibaba Clouds ApsaraDB RDS for MySQL läuft in seinen Festland-Regionen. Das sind echte inländische Optionen, aber jede ist ein anderer Betreiber und ein anderes Konto als der globale Dienst, den Sie vielleicht bereits nutzen, mit eigenem Funktionsumfang, eigener ICP-Beian und eigenen Compliance-Pflichten — eine inländische Region ist keine automatische Compliance.
Was es hält, sind personenbezogene Daten
Eine Datenbank ist, wo personenbezogene Daten physisch zur Ruhe kommen, was MySQL zur wortwörtlichsten Data-Residency-Frage macht, die Sie stellen können. Die Zeilen darin sind Namen, Kontaktdetails, Login-Zugangsdaten, Bestellhistorien, Zahlungsreferenzen — personenbezogene Daten nach Chinas Gesetz zum Schutz personenbezogener Daten. Sobald diese Informationen von Menschen in China gesammelt und in einem offshore gelegenen MySQL gespeichert werden, ist ihr Halten dort ein grenzüberschreitender Transfer, und jede Abfrage, die sie liest oder schreibt, bewegt personenbezogene Daten erneut über die Grenze. PIPL legt die Pflicht auf Sie — den Handler, nicht Oracle oder die Cloud — Mitteilung zu geben, gesonderte Einwilligung einzuholen und einen Transfermechanismus zu erfüllen: eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung (Artikel 38–43).
Für manche Handler geht das Recht weiter als ein Transfermechanismus und verlangt, dass die Daten bleiben, wo sie sind. Wenn Sie ein Betreiber kritischer Informationsinfrastruktur sind oder personenbezogene Daten oberhalb der regulierten Volumen-Schwellen verarbeiten, müssen im Festland gesammelte personenbezogene Daten im Festland gespeichert werden (Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37) — die Cybersicherheitsgesetz-Novelle von 2025, in Kraft seit 1. Januar 2026, nummerierte den Datenlokalisierungs-Artikel von 37 auf 39 um, Substanz unverändert; und PIPL Artikel 40). Ein offshore gelegenes MySQL, oder eine verwaltete Instanz in einer Nicht-China-Region, kann diese inländische Speicherpflicht strukturell nicht erfüllen — es gibt keine Festland-Kopie der Daten, auf die man zeigen könnte.
Es offshore zu betreiben erfüllt die Residency-Pflicht nicht — und was es tut
Die Lösung für eine offshore gelegene Residency-Lücke ist keine schnellere Verbindung zurück zur offshore gelegenen Datenbank — dieselben personenbezogenen Daten schneller über die Grenze zu bewegen lässt sie genauso offshore. Der rechtmäßige Hebel ist der, den MySQL Ihnen kostenlos reicht: die Engine im Inland betreiben. Weil MySQL quelloffene Software ohne Heimat-Region ist, können Sie einen MySQL-Server auf Festland-Infrastruktur aufstellen oder ein lizenziertes Sovereign-Cloud-verwaltetes MySQL übernehmen und die personenbezogenen Daten Ihrer chinesischen Nutzer auf chinesischem Boden halten — wo die Residency- und Lokalisierungspflichten bauartbedingt erfüllt statt umgangen werden.
Das zu tun bedeutet nicht, von MySQL wegzumigrieren oder Ihre Anwendung neu zu schreiben: es ist dieselbe Engine, dasselbe SQL, dasselbe Schema, jetzt in der richtigen Jurisdiktion ruhend. Was es braucht, ist die inländische Speicherung, die ICP-Beian für jede öffentliche China-gerichtete Oberfläche und eine rechtmäßige grenzüberschreitende Anordnung für die Daten, die wirklich gehen müssen. Diese Seite ist eine Risikokarte, kein Urteil — ob Sie inländische Speicherung, einen Transfermechanismus oder beides schulden, hängt von Ihrer Rechtsperson, Ihren Datenmengen und wessen personenbezogene Daten in der Datenbank sitzen ab, klären Sie also die Einzelheiten mit Rechtsbeistand, bevor Sie bauen.
Der rechtmäßige Pfad — kartieren, lokalisieren, ausliefern
Sie betreiben MySQL weiter. 21YunBox fügt das Stück hinzu, das eine offshore gelegene oder Global-Cloud-Datenbank nicht kann: ein rechtmäßiges, inländisches Zuhause für die Daten und eine ICP-eingereichte Art, sie zu erreichen.
- Kartieren. Unser China-Compliance-Team liest Ihre PIPL-Grenz-, Data-Residency- und Datenlokalisierungs- (CII) Pflichten und Ihre ICP-Pflichten gegen Ihre Rechtsperson, Ihre Datenmengen und wessen personenbezogene Daten in Ihrem MySQL sitzen.
- Lokalisieren. Wir betreiben MySQL im Inland — selbst-gehostet auf Festland-Infrastruktur oder auf einer lizenzierten Sovereign-Cloud-Option — sodass die personenbezogenen Daten Ihrer chinesischen Nutzer auf chinesischem Boden bleiben, mit eingewilligter, inländischer Speicherung für das, was bleiben muss. Lokalisieren heißt, ein rechtmäßiges inländisches MySQL aufzustellen, nicht auf einen offshore gelegenen Endpunkt zurückzugreifen.
- Ausliefern. Jede China-gerichtete Oberfläche vor der Datenbank — die App, der API-Edge, die Admin- und Reporting-Portale, die Ihre Festland-Nutzer erreichen — läuft über ICP-eingereichte, inländische Auslieferung (der 21YunBox Optimizer), vor dem Stack, den Sie bereits betreiben, ohne Neuaufbau und ohne zweite Codebasis.
21YunBox ist eine rechtskonforme Overlay, keine Migration, und ein Partner für MySQL und Ihre Cloud, kein Konkurrent zu ihnen. 21YunBox nutzt oder empfiehlt niemals Umgehung jeglicher Art. Das Ergebnis ist MySQL, das legal und rechtskonform für Ihre Nutzer in China läuft.
Compliance-Einschätzung anfordern →
Weiterführend:
- Grenzüberschreitende Datentransfers nach PIPL
- Chinas Cybersicherheitsgesetz und Datenlokalisierung
- Chinas Maßnahmen zur Sicherheitsbewertung der Datenausfuhr
- So erhalten Sie eine ICP-Beian für China
Häufige Fragen
Funktioniert MySQL in China, oder ist es gesperrt?
MySQL funktioniert und ist nicht gesperrt — es ist kostenlose, quelloffene Software, die Sie selbst installieren und betreiben, einschließlich auf Servern innerhalb des Festlands China. Die China-Frage ist nicht Erreichbarkeit, sondern Data Residency: wo die personenbezogenen Daten in Ihrem MySQL zur Ruhe kommen dürfen. Im Inland selbst zu hosten hält sie auf Festland-Boden; ein offshore gelegenes oder Nicht-China-Region-verwaltetes MySQL lässt sie außerhalb des Festlands, wo PIPLs Grenz- und Datenlokalisierungs-Regeln gelten.
Gibt es eine Festlandchina-Region für verwaltetes MySQL?
Nicht in den globalen Clouds. Amazon RDS und Aurora MySQL-Compatible, Azure Database for MySQL und Google Cloud SQL for MySQL deployen nur auf Regionen außerhalb des Festlands China — Google Cloud ist zum Beispiel „available in all Google Cloud regions", von denen keine im Festland ist (die nächsten sind Taiwan und Hongkong). Inländisches verwaltetes MySQL existiert nur auf separaten souveränen Clouds, die über ihre eigenen Konten erreicht werden: AWS Chinas aws-cn-Partition, betrieben von Sinnet und NWCD, Azure China betrieben von 21Vianet und Alibaba Clouds ApsaraDB RDS for MySQL. Das sind echte inländische Optionen, aber eine inländische Region ist keine automatische Compliance — jede bringt ihren eigenen Betreiber, ihre eigene ICP und ihre eigenen Pflichten.
Kann 21YunBox unser MySQL-Setup in China rechtskonform machen?
Ja. Unser China-Compliance-Team kartiert Ihre PIPL-Grenz-, Data-Residency- und Datenlokalisierungs-Exponierung gegen Ihre Rechtsperson, Ihre Datenmengen und wessen personenbezogene Daten in der Datenbank sitzen, dann betreibt es MySQL im Inland — selbst-gehostet auf Festland-Infrastruktur oder auf einer lizenzierten Sovereign-Cloud-Option — sodass die Daten Ihrer China-Nutzer auf Festland-Boden bleiben, mit jeder China-gerichteten Oberfläche, die über ICP-eingereichte, inländische Infrastruktur ausgeliefert wird, vor dem Stack, den Sie bereits betreiben. Kein Neuaufbau, keine Migration weg von MySQL. Nehmen Sie Kontakt auf, um Ihre konkreten Datenflüsse durchzuarbeiten.
