{"id":21427,"date":"2026-09-15T15:07:31","date_gmt":"2026-09-15T13:07:31","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-performance-regression-nach-updates-verhindern-optimiert-cluster\/"},"modified":"2026-09-15T15:07:31","modified_gmt":"2026-09-15T13:07:31","slug":"prevent-mariadb-performance-regression-after-updates-optimize-the-cluster","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/mariadb-performance-regression-nach-updates-verhindern-optimiert-cluster\/","title":{"rendered":"Avoiding MariaDB Performance Regression After Updates"},"content":{"rendered":"<p>Ich verhindere MariaDB Performance Regressionen nach Updates, indem ich \u00c4nderungen an Optimizer, Defaults und Statistiken vorab messe, vergleiche und gezielt absichere. Damit bleiben Antwortzeiten konstant, w\u00e4hrend ich neue Funktionen nutze und unn\u00f6tige Rollbacks vermeide.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n\n<ul>\n  <li><strong>Update-Plan<\/strong> statt Schnellschuss: Testen, messen, vergleichen, erst dann ausrollen.<\/li>\n  <li><strong>Optimizer-\u00c4nderungen<\/strong> verstehen: Pl\u00e4ne pr\u00fcfen, Statistiken aktualisieren, Optionen anpassen.<\/li>\n  <li><strong>Konfiguration<\/strong> nachziehen: Speicher, Logs, Parallelit\u00e4t und Caches auf die neue Version abstimmen.<\/li>\n  <li><strong>Monitoring<\/strong> sch\u00e4rfen: Slow Query Log, Latenzen, QPS und IO kontinuierlich beobachten.<\/li>\n  <li><strong>Rollback<\/strong> bereit halten: Snapshots, Backups, Replikation klar dokumentieren.<\/li>\n<\/ul>\n\n<h2>Ursachen erkennen: Warum Updates Leistung kosten k\u00f6nnen<\/h2>\n\n<p>Viele Einbr\u00fcche haben eine gemeinsame Wurzel: Der <strong>Optimizer<\/strong> \u00e4ndert Pl\u00e4ne, Defaults verschieben sich und alte Statistiken f\u00fchren zu Fehlentscheidungen. Ich analysiere zuerst, ob Abfragen pl\u00f6tzlich andere Indizes nutzen oder Full Scans ausl\u00f6sen. Danach pr\u00fcfe ich, welche Konfigurationswerte die neue Version still ver\u00e4ndert hat. Engine-Details wie InnoDB-Flush-Verhalten oder Join-Heuristiken spielen ebenfalls hinein. Erg\u00e4nzend schaue ich mir Kernel-Sicherheitsfixes an, weil sie IO-lastige Vorg\u00e4nge messbar bremsen k\u00f6nnen [1][2].<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-optimierung-server-8592.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kontrollierter Update-Plan statt Blindflug<\/h2>\n\n<p>Ich setze eine produktnahe Testumgebung mit echten Daten auf und halte Hardware und <strong>Konfiguration<\/strong> so \u00e4hnlich wie m\u00f6glich. Vor dem Upgrade erfasse ich Basiswerte wie Latenz, QPS, CPU und IO. Danach f\u00fchre ich das Update aus und wiederhole identische Workloads. Ich vergleiche Kennzahlen und konzentriere mich auf Abfragen, die klar l\u00e4nger laufen. F\u00fcr den Ernstfall halte ich eine saubere R\u00fcckfallebene bereit, zum Beispiel via Snapshot oder Replikation.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/MariaDBMeeting5987.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring sch\u00e4rfen: Slow Query Log und Latenzprofile<\/h2>\n\n<p>Ohne Metriken bleibt jede Optimierung ein <strong>Ratespiel<\/strong>. Direkt nach einem Upgrade aktiviere ich das Slow Query Log mit sinnvoller long_query_time und logge auch Queries ohne Index. Ich priorisiere die Auswertung nach H\u00e4ufigkeit und Gesamtlaufzeit, damit ich die gr\u00f6\u00dften Hebel zuerst angehe. F\u00fcr eine feinere Sicht nutze ich das <a href=\"https:\/\/webhosting.de\/mariadb-query-response-time-plugin-database-monitoring-analyse-focus\/\">Query Response Time Plugin<\/a> und zerlege Latenzen in Spannen. So erkenne ich, ob einzelne Planwechsel, Lock-Wartezeiten oder IO-Spitzen die Ursache darstellen [3].<\/p>\n\n<h2>Statistiken aktualisieren und Optimizer steuern<\/h2>\n\n<p>Direkt nach dem Update f\u00fchre ich ein fl\u00e4chiges <strong>ANALYZE<\/strong> \u00fcber kritische Tabellen durch. Persistente Statistiken m\u00fcssen den Ist-Zustand korrekt abbilden, sonst kippen Pl\u00e4ne in teure Scans. Bei deutlichen Abweichungen vergleiche ich EXPLAIN\/ANALYZE vor und nach dem Update. Wenn n\u00f6tig, justiere ich Optionen wie optimizer_switch oder selectivity-Settings. Bei kniffligen F\u00e4llen liefert mir der <a href=\"https:\/\/webhosting.de\/mariadb-optimizer-trace-sql-performance-analyse-datenbank\/\">Optimizer Trace<\/a> die entscheidenden Details, warum der Plan wechselt und wie ich gegensteuere [4].<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-regression-update-9823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Konfigurations-Tuning nach dem Upgrade<\/h2>\n\n<p>Viele Systeme verlieren Leistung, weil alte <strong>Defaults<\/strong> nicht mehr passen. Ich pr\u00fcfe zuerst den InnoDB-Buffer-Pool: Gr\u00f6\u00dfe, Anzahl der Instanzen und Latenzverhalten beim Flush. Auf Mehrkernservern lohnt ein Blick auf Thread-Pools und Verbindungsgrenzen. F\u00fcr Schreiblast entscheide ich, wie ich innodb_log_file_size, innodb_log_buffer_size und innodb_flush_log_at_trx_commit ausbalanciere. Wer tiefer einsteigen will, findet Hintergr\u00fcnde zu <a href=\"https:\/\/webhosting.de\/mariadb-buffer-pool-instances-mehrkernsysteme-performance-tuning-datenbank\/\">Buffer Pool Instances<\/a> und deren Auswirkung auf Parallelit\u00e4t [3][5].<\/p>\n\n<h2>Abfragen fit machen: Planvergleich, Indizes, Formulierungen<\/h2>\n\n<p>Ich vergleiche systematisch <strong>Pl\u00e4ne<\/strong> vor und nach dem Update mit EXPLAIN\/ANALYZE. Wenn gesch\u00e4tzte und tats\u00e4chliche Zeilen stark abweichen, setze ich zuerst bei Statistiken und Indizes an. Spalten in WHERE, JOIN, ORDER BY und GROUP BY brauchen passende Indexe, h\u00e4ufig kombiniert. Entferne ich \u00fcberz\u00e4hlige Indizes, sinkt die Schreiblast. Liefert die urspr\u00fcngliche Formulierung weiter schlechte Pl\u00e4ne, teste ich Alternativen wie andere Join-Reihenfolgen oder Unterabfragen [4][5].<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/MariaDBPerformance_2391.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Engine- und Systemaspekte klug ber\u00fccksichtigen<\/h2>\n\n<p>Ich pr\u00fcfe die eingesetzte <strong>Engine<\/strong>, weil MyISAM-Workloads mit vielen Table-Scans unter Kernel-Schutzmechanismen deutlich leiden k\u00f6nnen. In solchen F\u00e4llen bringt der Umstieg auf InnoDB oder Aria sp\u00fcrbare Vorteile. InnoDB selbst ver\u00e4ndert mit neuen Versionen Locking, Caching oder Statistiken, was in Summe messbare Effekte erzeugt. Ich gleiche diese Auswirkungen mit abgestimmter Konfiguration und frischen Statistiken aus. Zus\u00e4tzlich beobachte ich Storage-Latenzen, denn selbst kleine IO-Spr\u00fcnge schlagen sich direkt in Query-Zeiten nieder [2].<\/p>\n\n<h2>Rollout in Produktion: klein anfangen, sauber auswerten<\/h2>\n\n<p>Ein produktiver Rollout startet bei einer <strong>Replik<\/strong> mit echter Last und klaren Metriken. Ich plane das Zeitfenster in Phasen geringer Aktivit\u00e4t. W\u00e4hrend des Updates vergleiche ich Live-Kennzahlen mit meinen Basiswerten. Bei Abweichungen oberhalb definierter Schwellenwerte ziehe ich ein Downgrade oder Failback in Betracht. Dokumentierte Backups, Snapshots und Testl\u00e4ufe k\u00fcrzen die Reaktionszeit im Problemfall deutlich [1][5].<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_optimierung_8136.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Vergleichstabelle: typische \u00c4nderungen und Gegenma\u00dfnahmen<\/h2>\n\n<p>Die folgende \u00dcbersicht zeigt h\u00e4ufige \u00c4nderungen nach Updates, ihren m\u00f6glichen Effekt und meine <strong>Reaktion<\/strong>. Ich nutze sie als Checkliste w\u00e4hrend Tests. So verliere ich keine Stellschraube aus dem Blick. Ich kontrolliere jeden Punkt gegen Messwerte, nicht nach Bauchgef\u00fchl. Dadurch treffe ich belastbare Entscheidungen und halte Antwortzeiten konstant.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Parameter\/Feature<\/strong><\/th>\n      <th><strong>Effekt nach Update<\/strong><\/th>\n      <th><strong>Pr\u00fcfung\/Ma\u00dfnahme<\/strong><\/th>\n      <th><strong>Befehl\/Setting<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Optimizer-Plan<\/td>\n      <td>Wechsel auf teure Scans<\/td>\n      <td>EXPLAIN\/ANALYZE vergleichen, Trace pr\u00fcfen<\/td>\n      <td>EXPLAIN, ANALYZE, optimizer_switch<\/td>\n    <\/tr>\n    <tr>\n      <td>Statistiken<\/td>\n      <td>Falsche Kardinalit\u00e4ten<\/td>\n      <td>ANALYZE TABLE nach Upgrade<\/td>\n      <td>ANALYZE TABLE db.tbl<\/td>\n    <\/tr>\n    <tr>\n      <td>Buffer Pool<\/td>\n      <td>Mehr Page-Misses<\/td>\n      <td>Gr\u00f6\u00dfe\/Instanzen anpassen<\/td>\n      <td>innodb_buffer_pool_size\/_instances<\/td>\n    <\/tr>\n    <tr>\n      <td>Redo\/Flush<\/td>\n      <td>Schreib-Latenz steigt<\/td>\n      <td>Log-Gr\u00f6\u00dfen und Flush-Politik testen<\/td>\n      <td>innodb_log_file_size, innodb_flush_log_at_trx_commit<\/td>\n    <\/tr>\n    <tr>\n      <td>Thread\/Verbindungen<\/td>\n      <td>Contention bei Lastspitzen<\/td>\n      <td>Thread-Pool und Limits pr\u00fcfen<\/td>\n      <td>thread_pool_size, max_connections<\/td>\n    <\/tr>\n    <tr>\n      <td>Query Cache<\/td>\n      <td>Sperren bei Mischlast<\/td>\n      <td>Abschalten oder gezielt nutzen<\/td>\n      <td>query_cache_type\/size<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Best\u00e4ndige Vorbeugung: Tests, Standards, Pflege<\/h2>\n\n<p>Ich automatisiere Tests f\u00fcr <strong>Kernabfragen<\/strong> und lasse sie bei jedem gr\u00f6\u00dferen Upgrade in Staging laufen. Standardisierte Konfigurations-Templates in der Versionsverwaltung sorgen f\u00fcr Nachvollziehbarkeit. Regelm\u00e4\u00dfige Pflegearbeiten wie Statistik-Refresh, Index-Review und Log-Rotation senken das Risiko schleichender Einbr\u00fcche. Ein ganzheitlicher Blick auf App, Cache, Netzwerk und Storage verhindert, dass ich Symptome an der falschen Stelle behandle. Diese Routine spart Zeit, Nerven und Supportkosten [3][5].<\/p>\n\n<h2>Reproduzierbare Benchmarks statt Bauchgef\u00fchl<\/h2>\n\n<p>Ich achte darauf, dass Benchmarks <strong>vergleichbar<\/strong> bleiben: identische Datenst\u00e4nde, gleiche Concurrency-Profile und ein klarer Ablauf. Kalte und warme L\u00e4ufe trenne ich bewusst. Vor Messungen w\u00e4rme ich den Buffer Pool mit repr\u00e4sentativen Zugriffen an oder dokumentiere explizit, dass ich Kaltstarts vergleiche. Ich isoliere Nebeneffekte, indem ich Nebenjobs (Backups, ETL, Cron) w\u00e4hrend der Tests pausiere.<\/p>\n\n<p>Um Ausrei\u00dfer zu minimieren, fahre ich mehrere L\u00e4ufe und verwende Median sowie P95\/P99 statt nur Durchschnittswerten. Bei Leselast deaktiviere ich zur Messung Caches gezielt (zum Beispiel via SELECT-Varianten ohne Cache-Einfluss) und pr\u00fcfe, ob Ergebnisse stabil bleiben. F\u00fcr Schreibtests setze ich feste <strong>Transaktionsmuster<\/strong> und identische Batchgr\u00f6\u00dfen ein. So kann ich \u00c4nderungen in Optimizer, Logging und Storage-Stack sicher zuordnen.<\/p>\n\n<h2>Plan-Stabilit\u00e4t mit minimalinvasiver Steuerung<\/h2>\n\n<p>Neue Optimizer-Heuristiken k\u00f6nnen gute Pl\u00e4ne liefern \u2013 oder danebenliegen. Ich setze zuerst auf <strong>minimalinvasive<\/strong> Mittel, um Stabilit\u00e4t zur\u00fcckzugewinnen:<\/p>\n\n<ul>\n  <li><strong>Index-Hints<\/strong> bewusst einsetzen: USE\/FORCE\/IGNORE INDEX nur f\u00fcr hartn\u00e4ckige Problemabfragen, nicht pauschal.<\/li>\n  <li><strong>Join-Reihenfolge<\/strong> mit STRAIGHT_JOIN fixieren, wenn der Optimizer eine ung\u00fcnstige Permutation bevorzugt.<\/li>\n  <li><strong>optimizer_switch<\/strong> feinjustieren: ICP, MRR\/BKA, Semijoin-Strategien oder Skip-Scan selektiv an- oder abw\u00e4hlen, bis Statistiken wieder passen.<\/li>\n  <li><strong>Persistente Statistiken<\/strong> nach Struktur- oder Daten\u00e4nderungen refreshen; gro\u00dfe Abweichungen l\u00f6sen oft den Planwechsel aus.<\/li>\n<\/ul>\n\n<p>Ich dokumentiere jede Plansteuerung und evaluiere sie nach einigen Release-Zyklen neu. Ziel bleibt, Hints wieder entfernen zu k\u00f6nnen, sobald Statistiken und Defaults stabil liefern.<\/p>\n\n<h2>SQL-Mode, Zeichens\u00e4tze und Kollationen<\/h2>\n\n<p>Ein Update \u00e4ndert teils <strong>sql_mode<\/strong>-Defaults und Kollationsregeln. Das kann sich auf Sortierkosten, Vergleichslogik und Indexnutzung auswirken. Strengere Modi f\u00f6rdern Datenqualit\u00e4t, erzeugen aber bei Legacy-Workloads zus\u00e4tzliche Pr\u00fcfungen und Umwandlungen. Ich halte pro Release fest, welche Modi aktiv sind, und teste Sortierlast mit typischen LIKE\/ORDER-By-Mustern. Bei Unicode-lastigen Systemen pr\u00fcfe ich, ob ge\u00e4nderte Kollationen zu anderen <strong>Sortierreihenfolgen<\/strong> f\u00fchren und passe notfalls Indizes oder Query-Formulierungen an.<\/p>\n\n<h2>Temp-Tabellen, Sorts und Join-Pfade<\/h2>\n\n<p>Regressionsquellen sind oft <strong>Spills<\/strong> in On-Disk-Temp-Tabellen. Ich pr\u00fcfe, ob nach dem Upgrade mehr Sorts, GROUP BYs oder DISTINCTs auf Platte ausweichen. Stellschrauben sind tmp_table_size, max_heap_table_size, join_buffer_size, sort_buffer_size und bei Aria die Page-Cache-Gr\u00f6\u00dfe. Ich teste schrittweise, ob gr\u00f6\u00dfere In-Memory-Limits die Zahl der On-Disk-Temp-Tabellen senken, ohne Speicherdruck und OOM-Risiken zu erh\u00f6hen. Parallel kontrolliere ich, ob Formulierungen (zum Beispiel unn\u00f6tige ORDER BYs) bereinigt werden k\u00f6nnen.<\/p>\n\n<h2>Buffer-Pool-Warmup und Hintergrundarbeit<\/h2>\n\n<p>Nach Upgrades \u00e4ndern sich oft <strong>Hintergrund-Algorithmen<\/strong> f\u00fcr Flush, Purge und Adaptive-Mechanismen. Ich kalibriere innodb_io_capacity, Purge-Threads und das Flush-Verhalten im Zusammenspiel mit dem Storage-Subsystem. Ein abgestimmtes Warmup \u2013 zum Beispiel \u00fcber Buffer-Pool-Dump\/Load oder zielgerichtete Workloads \u2013 verk\u00fcrzt die Lernphase nach dem Deploy. Wichtig ist, Lese- und Schreibpfade getrennt zu beobachten: Steigt der Insert-Lag, pr\u00fcfe ich zuerst Redo\/Flush und Checkpoint-Abst\u00e4nde, nicht den Optimizer.<\/p>\n\n<h2>Replikation und Cluster: Rolling Upgrades ohne Risiko<\/h2>\n\n<p>Bei asynchroner Replikation starte ich auf einer <strong>Lag-freien<\/strong> Replik und lasse realen Traffic kontrolliert einlaufen. Ich vergleiche Metriken der Replik mit dem Primary, bevor ich weiterrolle. GTID- und Binlog-Settings (Row- vs. Statement-basiert) k\u00f6nnen Write-Amplification und Replikationslatenz sp\u00fcrbar ver\u00e4ndern; ich messe diese Effekte gesondert.<\/p>\n\n<p>In Cluster-Setups (zum Beispiel mit synchroner Replikation) achte ich auf Flow-Control, Write-Set-Konflikte und donor\/receiver-Auswirkungen beim State-Transfer. Ein Upgrade-Korridor mit limitierter Concurrency verhindert, dass einzelne Knoten in <strong>Backpressure<\/strong> laufen. Ich definiere klare Stop-Kriterien (zum Beispiel P95-Latenz \u00fcber Schwelle X f\u00fcr Y Minuten), um den Rollout geordnet zu pausieren.<\/p>\n\n<h2>OS, Virtualisierung und Container<\/h2>\n\n<p>Kernel- und Hypervisor-Details verst\u00e4rken oder d\u00e4mpfen Update-Effekte. Ich dokumentiere CPU-Governor, NUMA-Layout, riesige\/transparent gro\u00dfe Seiten, IRQ-Verteilung und IO-Scheduler. Selbst kleine \u00c4nderungen hier verschieben die Balance zwischen CPU-Wartezeiten und IO-Latenz. Nach Security-Patches messe ich IO-intensive Workloads separat, um Scheinregressionen vom Datenbank-Stack zu trennen [1][2]. In Containern pr\u00fcfe ich Cgroup-Limits und Storage-Treiber, damit Messungen nicht an <strong>Throttling<\/strong> oder Copy-on-Write scheitern.<\/p>\n\n<h2>Gezielte Fehleranalyse: Von Symptom zu Ursache<\/h2>\n\n<p>Wenn einzelne Endpunkte aus der Reihe tanzen, ordne ich sie entlang der Kette zu: Applikation \u2192 Netzwerk \u2192 Datenbank \u2192 Storage. In der Datenbank beginne ich mit dem Slow Log und aggregiere nach <strong>Query-Digest<\/strong>, um gleiche Abfragen zusammenzufassen. Danach vergleiche ich Pl\u00e4ne alt\/neu, pr\u00fcfe Locks\/Blocker und schaue auf den Anteil On-Disk-Temp-Tabellen. Ein Ampelmodell hilft: gr\u00fcn (nur Varianz), gelb (Planwechsel, korrigierbar), rot (systemischer Engpass wie Flush oder IO). So entscheide ich schnell, ob Tuning reicht oder ein kontrollierter Failback n\u00f6tig ist.<\/p>\n\n<h2>Governance, SLOs und Freigabeprozess<\/h2>\n\n<p>Ich arbeite mit <strong>Regression-Budgets<\/strong>: maximal zul\u00e4ssige P95\/P99-Degradation pro Endpoint. Diese Budgets sind Teil des Freigabeprozesses. Vor dem Go-Live stehen: dokumentierte Basiswerte, Abnahmekriterien, Backout-Plan und Owner. W\u00e4hrend des Rollouts gibt es ein kurzes Standup mit klaren Schwellenwerten und einem \u201eStop-Button\u201c. Nach erfolgreicher Umstellung archiviere ich Messungen und Tuning-Entscheidungen, damit kommende Updates schneller und sicherer werden.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-optimierung-4759.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kurzbilanz f\u00fcr Admins<\/h2>\n\n<p>Wer Updates planvoll testet, saubere <strong>Metriken<\/strong> erhebt und Konfigurations\u00e4nderungen bewusst vornimmt, h\u00e4lt Antwortzeiten verl\u00e4sslich. Ich starte mit einer realit\u00e4tsnahen Staging-Umgebung und messe jede \u00c4nderung. Frische Statistiken, ein kritischer Blick auf Optimizer-Entscheidungen und ein angepasstes Tuning entsch\u00e4rfen fast jede Regression. F\u00fcr schwierige F\u00e4lle liefern Trace, Slow Log und gezielte A\/B-Vergleiche klare Hinweise. Mit vorbereitetem Rollback bleibe ich handlungsf\u00e4hig und nutze neue Versionen sicher [1][4][5].<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how to avoid MariaDB performance regression after a `mariadb update` and ensure stable, fast databases through targeted database tuning.<\/p>","protected":false},"author":1,"featured_media":21420,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21427","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"108","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"MariaDB Performance","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21420","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21427","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=21427"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21427\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/21420"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=21427"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=21427"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=21427"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}